Skip to content

fix(schedule): stop stray 'days' data from overriding Global schedule#399

Merged
ChuckBuilds merged 1 commit into
mainfrom
claude/global-schedule-bug-ebx7m2
Jul 12, 2026
Merged

fix(schedule): stop stray 'days' data from overriding Global schedule#399
ChuckBuilds merged 1 commit into
mainfrom
claude/global-schedule-bug-ebx7m2

Conversation

@ChuckBuilds

Copy link
Copy Markdown
Owner

Summary

Fixes a bug where a display schedule set to "Global" would silently blank the display on certain days, logging that "Saturday wasn't active" even though the user never configured per-day settings.

Root cause

  • save_schedule_config in web_interface/blueprints/api_v3.py never persisted the schedule's mode field to config.json (unlike the dim schedule's save handler, which does).
  • _check_schedule in src/display_controller.py decided global-vs-per-day purely by checking whether a days dict happened to be present for the current weekday — it never consulted mode.
  • config_manager._merge_template_defaults (config migration) re-adds any template key missing from the user's saved config, including schedule.days — which is exactly the key the "Global" save path intentionally removes. So after saving Global mode, the next config load/migration resurrects schedule.days from the template (all days enabled: false), and _check_schedule treats it as authoritative, disabling the display on any day it finds there.

Fix

  • Persist mode when saving the schedule (mirrors the existing dim-schedule save behavior).
  • Make _check_schedule honor an explicit mode field (mirrors the existing _check_dim_schedule logic), so a resurrected/stray days dict can no longer override an explicit Global selection. Falls back to the previous inference-from-days-presence behavior only for legacy configs with no recorded mode.

Type of change

  • Bug fix

Related issues

Reported by a user: Global Schedule would shut off the display, with logs showing "Saturday wasn't active" despite Global mode being selected.

Test plan

  • Ran on a real Raspberry Pi with hardware
  • Ran in emulator mode (EMULATOR=true python3 run.py)
  • Ran the dev preview server (scripts/dev_server.py)
  • Ran the test suite (pytest)
  • Manually verified the affected code path in the web UI

Existing pytest schedule tests could not be executed in this sandbox (missing system deps for RGBMatrixEmulator/freetype hardware stack). Verified the new _check_schedule branching logic directly with a standalone script covering: global mode with a stray/resurrected days dict (bug repro — now correctly ignored), legacy config with no mode + per-day match, legacy config with no mode + day missing (falls back to global), explicit per-day mode, and explicit global mode with no days key at all.

Documentation

  • N/A — no docs needed

Plugin compatibility

  • N/A — change doesn't touch the plugin system

Checklist

  • I've not committed any secrets or hardcoded API keys
  • If this adds a new config key, the form in the web UI was verified (the form is generated from config_schema.json) — N/A, no new config key added, mode was already part of the schedule-picker widget's payload.

Notes for reviewer

The dim schedule (dim_schedule) already correctly persists and checks mode, so it was unaffected by this bug — only the primary display schedule was missing this.


Generated by Claude Code

save_schedule_config never persisted the schedule's 'mode' field, and
_check_schedule inferred per-day vs global purely from whether a 'days'
dict was present for the current day. Config migration
(_merge_template_defaults) re-adds the template's 'schedule.days' (all
days disabled by default) whenever it's missing from the user's saved
config - which is exactly the case after saving Global mode, since that
save path intentionally pops 'days'. The result: a user on Global mode
would get their schedule silently reinterpreted as per-day, with today's
day disabled, blanking the display.

Persist 'mode' on save and have _check_schedule honor it explicitly
(mirroring how _check_dim_schedule already does), so a resurrected
'days' dict can't override an explicit Global selection. Falls back to
the old inference behavior only when no 'mode' is recorded.
@coderabbitai

coderabbitai Bot commented Jul 12, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@ChuckBuilds, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 31 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 14da3d29-bff1-4488-bc02-4aa90af5ab5c

📥 Commits

Reviewing files that changed from the base of the PR and between 05e7c43 and a0c80d9.

📒 Files selected for processing (2)
  • src/display_controller.py
  • web_interface/blueprints/api_v3.py
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch claude/global-schedule-bug-ebx7m2

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric Results
Complexity 0
Duplication 0

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@ChuckBuilds ChuckBuilds merged commit 6edd80d into main Jul 12, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants