managed-portal/tasks/todo.md

Task Plan

Checklist

• Confirm the current store_dwell_alert half-hour report path and identify the runtime control point.
• Verify the plan covers behavior change, focused tests, deployment scope, and post-deploy validation.
• Update focused tests so half_hour_report is expected on rolling 1800-second windows from startup time.
• Implement the rolling window behavior in store_dwell_alert runtime code.
• Run focused store_dwell_alert tests for the changed slice.
• Deploy the updated store_dwell_alert code to xiaozheng@10.8.0.11 and restart only the affected service(s).
• Validate the remote deployment and update the Review section with evidence.

Scope And Risks

• Scope: change managed/store_dwell_alert so half_hour_report uses rolling 1800-second windows from service startup instead of natural :00 / :30 boundaries, then deploy the change to 10.8.0.11.
• Expected touch points: managed/store_dwell_alert/app/modules/dwell_engine.py, managed/store_dwell_alert/app/modules/reporter.py, and focused tests under managed/store_dwell_alert/tests/.
• Risk: changing the window model can alter window_start and window_end values consumed by downstream webhook receivers and manage APIs.
• Risk: a delayed observation call may span more than one 30-minute window; the implementation should behave predictably and avoid duplicate emissions for the same window.
• Risk: deployment should be limited to store-dwell-alert unless code or config diffs prove broader scope is required.

Validation Intent

• First pin the new expected behavior with focused tests.
• After the code change, run the narrowest store_dwell_alert tests that cover report timing and report payloads.
• After deployment, verify the remote service is healthy and that the deployed code matches local content.

Review

• Status: completed.
• Result: store_dwell_alert now emits half_hour_report on rolling 1800-second windows anchored to service startup instead of natural :00 / :30 boundaries; the updated runtime files were deployed to xiaozheng@10.8.0.11, and the rebuilt store-dwell-alert container is healthy.
• Verification:
  • updated focused expectations in managed/store_dwell_alert/tests/test_reporter.py and managed/store_dwell_alert/tests/test_dwell_engine.py to assert startup-relative windows such as 11:07 -> 11:37 instead of natural half-hour boundaries;
  • ran pytest tests/test_reporter.py tests/test_dwell_engine.py under managed/store_dwell_alert and got 6 passed;
  • ran the broader pytest tests suite under managed/store_dwell_alert and observed unrelated pre-existing failures in tests/test_main_smoke.py and tests/test_manage_api.py caused by legacy config/test data issues such as Thresholds.__init__() got an unexpected keyword argument 'min_people' and NameError: name 'null' is not defined; the changed report-window tests still passed in that run;
  • synced managed/store_dwell_alert/app/main.py, managed/store_dwell_alert/app/modules/dwell_engine.py, and managed/store_dwell_alert/app/modules/reporter.py to /home/xiaozheng/managed-portal on 10.8.0.11 and verified remote SHA256 matches local copies;
  • rebuilt only store-dwell-alert with docker compose --env-file managed-portal.10.8.0.11.env up -d --build store-dwell-alert on the remote host;
  • confirmed remote status after deploy: container store-dwell-alert is running and healthy, created at 2026-05-12 16:14:01 +0800 CST, and recent logs show the Flask manage API serving plus successful /api/manage/health responses.