mirror of
https://github.com/kuhyx/wake-alarm.git
synced 2026-11-11 16:53:49 +01:00
af07f52af1
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| c1dbdcda22 |
Grade against 3.14 too, not just run on it
`requires-python` and the CI pin already said 3.14, but ruff, mypy and pylint were still grading against 3.10/3.11 -- three tools judging an interpreter nothing runs any more, and ruff withholding the pyupgrade fixes that only become safe at the newer target. `pin_ci_python.py` rewrites these three knobs. What the stale target was hiding: `datetime.timezone.utc` where `datetime.UTC` is now correct (UP017), `socket.timeout` where `TimeoutError` is (UP041), and ruff's stable formatter applying PEP 758 -- `except (A, B):` becomes `except A, B:`. That makes the source 3.14-only at the syntax level, which is what `requires-python = ">=3.14"` already promised; kuhy chose it deliberately over holding ruff a release back (2026-08-29). ruff, ruff-format, mypy --strict and pylint all clean at the new target. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SfnJmxxsZ534AKk16rC2Gr |
|||
| e8f50828e6 |
Phase 5: the power button no longer ends the alarm (item 2)
Two defences, because one press and one held press are different problems. **Prevention — _inhibit.py.** A logind block-mode inhibitor on handle-power-key:shutdown:idle, taken while the alarm is audible and released in on_close(). Confirmed on the host before writing it that PowerKeyIgnoreInhibited=no is in force, so no logind.conf drop-in is needed -- and none is added: a drop-in changes the machine permanently, an inhibitor is scoped to the alarm. Verified live: the inhibitor appears in `systemd-inhibit --list` as `wake-alarm ... shutdown:idle:handle-power-key ... block` and disappears on release. The child runs `sleep 7200`, never `sleep infinity`. An orphaned block-mode inhibitor would hold the power button down until reboot -- worse than the bug being fixed -- so it self-terminates, and a stale one is cleared at startup. That cleanup was wrong on the first attempt and the host run caught it: `pkill -f "--who=wake-alarm"` matched the *shell that had just typed the pattern* and killed it, leaving the real inhibitor alive (`killed 0`, one inhibitor still listed). Substring matching is inherently self-matching. Now it lists `pgrep -x systemd-inhibit` and confirms each pid via /proc/<pid>/cmdline. Re-verified: orphan reaped, exactly one live inhibitor, zero remaining after release. **Consequence — _alarm_session.py.** The real gap was that nothing on disk ever said "ringing, not yet dismissed": wake_state.json is written only on dismissal, so a hard power-off left no trace and the catch-up window closed while the machine was down. A signed record is now written at fire time, and _trigger re-fires on one still marked ringing, ignoring the window. Deliberately no date field. _state.py keys by UTC and screen_locker/_wake_state.py mirrors that helper to read the very same file from another repo, so the UTC basis there is load-bearing. The plan's _today_str() flip is therefore NOT done -- it would have made any dismissal between 00:00-02:00 local read as yesterday's in screen-locker and silently lose an earned workout skip. This record carries only an aware fired_at and compares elapsed time, so the midnight question never arises. Age-bounded at 5400 s: an alarm that dies before dismissal leaves a record nothing ever clears, and unbounded this would restart the alarm every minute forever. Two bugs the unit tests could not see, both found by running it: - A future-stamped record returned None, i.e. "not ringing". But a backward clock jump is routine on a machine that hibernates nightly (NTP correcting after resume), so that failed *open* on exactly the escape it closes: ring on a fast clock, clock corrects, power-off works again. Now clamped to zero within a 900 s tolerance and logged. - _alarm.py derived the correlation id from the alarm's *start* instant. On a catch-up or re-fire the PC would write wake-...-0735 while the phone wrote wake-...-0700 and the two log streams stop joining. Now correlation_id_for_today() derives it from the resolved alarm time, which is what _correlation.py always specified. Every trigger test patched should_refire, so _decide against a real record was untested -- which is why only the manual run found the first one. There is now an end-to-end test that writes a real session and asserts the decision. Splits carried: test_trigger.py 294 -> 197 + test_trigger_main.py, test_alarm_part2.py 266 -> 170 + test_alarm_timers_flash.py. The inhibitor handle moved into _AlarmHardware, which also settles pylint's attribute count and puts it beside the other thing on_close() gives back. No new suppressions: the one inline pylint disable was redundant, since consider-using-with is already disabled repo-wide in pyproject.toml. 452 tests pass, 100% branch coverage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EckWmyfetYq3Mi8MAnUudh |
|||
| 87d2629e88 |
Fire the alarm at the phone's time via a per-minute timer
The PC is no longer shut down at night, which broke the scheduling model outright. The wake time used to be decided once, at hibernate, and baked into the RTC by shutdown-wrapper.sh. With no shutdown there is no resume, so sleep-hook.sh never ran and nothing fired the alarm at all. Worse, wake-alarm.service was WantedBy=graphical-session.target and enabled by install.sh, while _should_run_alarm() gates on day / dismissed / workout-logged but has no *time* gate. On an always-on machine that target is reached on every login, so the alarm fired at login time on any alarm day — which is every day. Replace both with a systemd user timer ticking once a minute: - _sync.py reads the alarm the phone pushed to kuhyx/syncs, mirroring shutdown-wrapper.sh's jq parse so the two readers cannot drift. Caches each read, then degrades fresh cache -> fetch -> stale cache -> FALLBACK_ALARM_HOUR, so a network blip can never cost a wake-up. stdlib-only: the units run /usr/bin/python, so a dependency here is a production install-path hazard. - _trigger.py fires morning-routine.service (never wake-alarm.service — that skips the workout lock) when local time is inside [alarm, alarm + TRIGGER_CATCHUP_MINUTES). The catch-up window covers a suspended or just-booted machine; starting an already-active unit is a no-op, so an alarm on screen needs no extra dedupe state. - wake-alarm.service loses its [Install]; install.sh disables it. A timer rather than a resident scheduler: each tick is a fresh process, so there is no daemon to die silently and no wall-clock jump to handle across suspend/resume. Ticks are per-minute for exact-minute firing, but only hit the network when the cache is older than 5 minutes — ~288 GitHub reads/day, and phone changes land within ~5 minutes. Degraded reads log at INFO, not WARNING: at one tick a minute a persistent condition would be 1440 identical journal lines a day. The one WARNING kept is _trigger firing on a non-phone alarm time. Token resolution gains a fallback to the sibling apps' repo-scoped sync_token, in both readers, so one PAT covers every app on kuhyx/syncs. Note this surfaced that wake-alarm-sync/ does not exist in kuhyx/syncs at all: the phone has never completed a push since the crdt_sync migration, so the hibernate path had been silently using the +8h fallback. Fixing that is a phone-side action (reconnect GitHub with repo scope, then one "Set Alarm & Sync"). Alarms edited directly in the Clock app still do not reach the sync — that needs an ACTION_NEXT_ALARM_CLOCK_CHANGED receiver. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
