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

New issue

Closed

opened 2026-07-15 15:33:07 +00:00 by claude-bot · 2 comments

claude-bot commented

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

Contributor

Split from #40. services/priority_resolver.get_events_for_date correctly implements spec §2.5 (date-level primary pins, secondaries, user-event shadowing) but is referenced only by its own tests. The real push paths — routers/wled.py::push_today (naive max(priority) query at lines 157–162) and services/schedule_service.py (~line 279) — bypass it entirely, so pinning a date or clicking "Promote Secondary" in the UI changes nothing on the controller.

Tasks

Replace the ad-hoc event queries in push_today and the scheduler's daily push with get_events_for_date
Audit any other resolution sites (export, preset sync, candidate generation) for the same bypass
Tests: a pinned date pushes the pinned event's scheme; a user override row shadows its parent event in the push path

Acceptance

Setting a pin via PUT /event-date-overrides/{date} changes what POST /wled/push sends that day

Split from #40. `services/priority_resolver.get_events_for_date` correctly implements spec §2.5 (date-level primary pins, secondaries, user-event shadowing) but is referenced only by its own tests. The real push paths — `routers/wled.py::push_today` (naive `max(priority)` query at lines 157–162) and `services/schedule_service.py` (~line 279) — bypass it entirely, so pinning a date or clicking "Promote Secondary" in the UI changes nothing on the controller. ## Tasks - [ ] Replace the ad-hoc event queries in `push_today` and the scheduler's daily push with `get_events_for_date` - [ ] Audit any other resolution sites (export, preset sync, candidate generation) for the same bypass - [ ] Tests: a pinned date pushes the pinned event's scheme; a user override row shadows its parent event in the push path ## Acceptance - [ ] Setting a pin via `PUT /event-date-overrides/{date}` changes what `POST /wled/push` sends that day

claude-bot added this to the v1.0.0 milestone

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

claude-bot added the

labels

2026-07-15 15:33:07 +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 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:26 +00:00

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

claude-bot referenced this issue

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

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

claude-bot referenced this issue

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

Revert quick-push at the on scheduler event #47

claude-bot commented

2026-07-16 05:02:48 +00:00

Author

Contributor

Picking this up as the foundation of the Wave-2 push-path cluster. Per the heads-up above, #43/#44/#45/#47 share files, so I'm doing them sequentially on one branch (fix/43-push-paths), starting with this resolver wiring — the others continue on the same branch. Based on the now-green main (#41 merged).

Picking this up as the foundation of the Wave-2 push-path cluster. Per the heads-up above, #43/#44/#45/#47 share files, so I'm doing them **sequentially on one branch** (`fix/43-push-paths`), starting with this resolver wiring — the others continue on the same branch. Based on the now-green main (#41 merged).