yangyl/managed-portal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4e2ca3cff7b716145804722d13f40c2ff383812e
managed-portal/tasks/todo.md
skye.yue 4e2ca3cff7 feat: improve webhook filtering, worker status startup handling, and timestamp parsing 
- Skip half_hour_report events from webhook posts in people_flow
- Handle pre-existing stale worker status files during startup gracefully
- Make store_dwell_alert timestamp parsing robust against invalid/empty values
- Update lessons learned and todo documentation

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-06-10 17:05:31 +08:00

2.7 KiB
Raw Blame History

Task Plan

Checklist

  • Review repo guidance, recent lessons, and the validated .14/.18 webhook-to-MQTT setup.
  • Inspect xiaozheng@10.8.0.15 for video-recognition image digest/tag, store-dwell-alert webhook config, and current summary data.
  • Compare .15 against the validated setup to determine whether the issue is missing webhook config, wrong image content, malformed summary data, or a combination.
  • Apply the minimum .15 fix if the host is misconfigured.
  • Verify on .15 that store-dwell-alert summary reads cleanly and the webhook receiving path is available.

Scope And Risks

  • Scope: check whether .15 has the same webhook/image/summary problem pattern already seen on .14 and .18, and correct it if needed.
  • Scope: keep changes limited to .15 live deployment inputs and runtime state for store-dwell-alert and video-recognition.
  • Risk: .15 may have host-specific stream assignments and local dev containers, so fixes must preserve its existing RTSP settings.
  • Risk: if .15 still runs an older local store-dwell-alert:dev, a manual webhook test can create malformed summary data; any test record must be cleaned up afterward.

Validation Intent

  • Capture .15 live config and image state before making changes.
  • If changes are needed, verify the final video-recognition digest, the store-dwell-alert webhook URL, the summary endpoint behavior, and the webhook receiving path on .15.

Review

  • Status: complete.
  • Result: .15 store-dwell-alert was already correctly configured with webhook.url: http://host.docker.internal:8080/api/webhook/managed-queue, and its summary was healthy. The only misalignment was video-recognition, which was still on old digest sha256:4e098feb...; I updated it by pulling the current ota.zhengxinshipin.com:5443/ota/video-recognition:1.0.0 and recreating the service. The registry currently served digest sha256:0ebb05f2... to .15.
  • Verification:
    • Before update, .15 video-recognition container/image digest was sha256:4e098feb4505aeb2b5e718e7017d81ab08ea8d5a91467ec828d1acdb9de4752a.
    • .15 store-dwell-alert runtime config already had webhook.url: http://host.docker.internal:8080/api/webhook/managed-queue, and /api/manage/summary returned 200 with last_result_time=2026-06-10T11:08:58.026758+08:00.
    • After docker pull and recreate, .15 video-recognition runs sha256:0ebb05f2a1765b5322a8194014e914ab9dd2e10815da49bc0f5a42ab4df8a723, matching the digest returned by the registry to .15.
    • After the update, POST http://127.0.0.1:8080/api/webhook/managed-queue returned HTTP 200 with forwarded_to_mqtt:true, and video-recognition logged POST "/api/webhook/managed-queue" 200.