yangyl/managed-portal
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: implement rolling half-hour report windows anchored to service startup time

Browse Source
This commit is contained in:
skye.yue
2026-05-12 16:17:08 +08:00
parent 4e69eca7cb
commit 454b716f89
6 changed files with 112 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
tasks/todo.md
View File

@@ -4,11 +4,11 @@
- [x] Confirm the current `store_dwell_alert` half-hour report path and identify the runtime control point.
- [x] 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.
- [x] Update focused tests so `half_hour_report` is expected on rolling 1800-second windows from startup time.
- [x] Implement the rolling window behavior in `store_dwell_alert` runtime code.
- [x] Run focused `store_dwell_alert` tests for the changed slice.
- [x] Deploy the updated `store_dwell_alert` code to `xiaozheng@10.8.0.11` and restart only the affected service(s).
- [x] Validate the remote deployment and update the Review section with evidence.
## Scope And Risks
@@ -26,6 +26,12 @@
## Review
- Status: in progress.
- Result: pending.
- Verification: pending.
- 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.