Finish fallback policies: 5-minute spaced retries and last_known_good re-push on reconnect #45

New issue

Closed

opened 2026-07-15 15:33:08 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-07-15 15:33:08 +00:00

Contributor

Split from #40. Spec §5.3 defines three fallback policies; two are incomplete in services/wled_push.py:

retry: spec says "3 times at 5-minute intervals"; implementation retries immediately in a loop (lines ~48–71, docstring itself defers spacing to "M4")
last_known_good: stores the intended state but nothing ever re-pushes it — there is no reconnect detection, so the policy is a no-op beyond silent+logging

Tasks

Schedule spaced retries via APScheduler (survives restarts through the persistent jobstore) instead of inline sleeps
Add a lightweight reconnect watcher (periodic status poll while in a failed state) that pushes the currently-expected scheme once the controller answers, then stops polling
push_failed webhook only after the final retry, not the first failure
Tests: clock-driven retry spacing; reconnect triggers exactly one catch-up push

Split from #40. Spec §5.3 defines three fallback policies; two are incomplete in `services/wled_push.py`: - `retry`: spec says "3 times at 5-minute intervals"; implementation retries immediately in a loop (lines ~48–71, docstring itself defers spacing to "M4") - `last_known_good`: stores the intended state but nothing ever re-pushes it — there is no reconnect detection, so the policy is a no-op beyond `silent`+logging ## Tasks - [ ] Schedule spaced retries via APScheduler (survives restarts through the persistent jobstore) instead of inline sleeps - [ ] Add a lightweight reconnect watcher (periodic status poll while in a failed state) that pushes the currently-expected scheme once the controller answers, then stops polling - [ ] `push_failed` webhook only after the final retry, not the first failure - [ ] Tests: clock-driven retry spacing; reconnect triggers exactly one catch-up push

claude-bot added this to the v1.0.0 milestone

2026-07-15 15:33:08 +00:00

claude-bot added the

labels

2026-07-15 15:33:08 +00:00

claude-bot referenced this issue

2026-07-15 15:33:17 +00:00

Spec-compliance review (2026-07-15): findings & gap list #40

claude-bot referenced this issue

2026-07-15 15:42:26 +00:00

Wire priority_resolver into push paths — date pins & Promote Secondary have no runtime effect #43

claude-bot referenced this issue

2026-07-15 15:42:26 +00:00

Honor the no-event default_scheme setting (off / dim_white / scheme reference) #44

claude-bot commented

2026-07-15 15:42:26 +00:00

Author

Contributor

Implementation heads-up (from the 2026-07-15 review): this issue overlaps files with #43, #44, #45, and #47 — all four touch backend/app/services/schedule_service.py and/or services/wled_push.py / routers/wled.py. Work them sequentially on one branch (or rebase between each) rather than in parallel branches, or the merge conflicts will cost more than the parallelism saves.

Deployment note until #65 lands: rebuild on the dev server with docker compose build — never docker build -t iris:latest . (compose uses the image name iris-wled-iris:latest; a manually tagged build is ignored and the container keeps running stale layers).

**Implementation heads-up (from the 2026-07-15 review):** this issue overlaps files with #43, #44, #45, and #47 — all four touch `backend/app/services/schedule_service.py` and/or `services/wled_push.py` / `routers/wled.py`. Work them **sequentially on one branch** (or rebase between each) rather than in parallel branches, or the merge conflicts will cost more than the parallelism saves. Deployment note until #65 lands: rebuild on the dev server with `docker compose build` — **never** `docker build -t iris:latest .` (compose uses the image name `iris-wled-iris:latest`; a manually tagged build is ignored and the container keeps running stale layers).

claude-bot referenced this issue

2026-07-15 15:42:27 +00:00

Revert quick-push at the on scheduler event #47