- 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>
2.7 KiB
2.7 KiB
Task Plan
Checklist
- Review repo guidance, recent lessons, and the validated
.14/.18webhook-to-MQTT setup. - Inspect
xiaozheng@10.8.0.15forvideo-recognitionimage digest/tag,store-dwell-alertwebhook config, and current summary data. - Compare
.15against the validated setup to determine whether the issue is missing webhook config, wrong image content, malformed summary data, or a combination. - Apply the minimum
.15fix if the host is misconfigured. - Verify on
.15thatstore-dwell-alertsummary reads cleanly and the webhook receiving path is available.
Scope And Risks
- Scope: check whether
.15has the same webhook/image/summary problem pattern already seen on.14and.18, and correct it if needed. - Scope: keep changes limited to
.15live deployment inputs and runtime state forstore-dwell-alertandvideo-recognition. - Risk:
.15may have host-specific stream assignments and localdevcontainers, so fixes must preserve its existing RTSP settings. - Risk: if
.15still runs an older localstore-dwell-alert:dev, a manual webhook test can create malformed summary data; any test record must be cleaned up afterward.
Validation Intent
- Capture
.15live config and image state before making changes. - If changes are needed, verify the final
video-recognitiondigest, thestore-dwell-alertwebhook URL, the summary endpoint behavior, and the webhook receiving path on.15.
Review
- Status: complete.
- Result:
.15store-dwell-alertwas already correctly configured withwebhook.url: http://host.docker.internal:8080/api/webhook/managed-queue, and its summary was healthy. The only misalignment wasvideo-recognition, which was still on old digestsha256:4e098feb...; I updated it by pulling the currentota.zhengxinshipin.com:5443/ota/video-recognition:1.0.0and recreating the service. The registry currently served digestsha256:0ebb05f2...to.15. - Verification:
- Before update,
.15video-recognitioncontainer/image digest wassha256:4e098feb4505aeb2b5e718e7017d81ab08ea8d5a91467ec828d1acdb9de4752a. .15store-dwell-alertruntime config already hadwebhook.url: http://host.docker.internal:8080/api/webhook/managed-queue, and/api/manage/summaryreturned200withlast_result_time=2026-06-10T11:08:58.026758+08:00.- After
docker pulland recreate,.15video-recognitionrunssha256:0ebb05f2a1765b5322a8194014e914ab9dd2e10815da49bc0f5a42ab4df8a723, matching the digest returned by the registry to.15. - After the update,
POST http://127.0.0.1:8080/api/webhook/managed-queuereturned HTTP200withforwarded_to_mqtt:true, andvideo-recognitionloggedPOST "/api/webhook/managed-queue"200.
- Before update,