fix(sleep): don't show 'awaiting confirmation' for a persisted alarm#120
Merged
abdulsaheel merged 1 commit intoJul 21, 2026
Merged
Conversation
The Sleep page's alarm caption fell through to 'Alarm sent, waiting for the strap to confirm.' whenever a persisted alarm epoch existed, so a fresh open showed the pending status even though the user never tapped 'Set band alarm' this session. The strap-confirmation state machine is session-scoped and records no SET on a fresh launch, so route the caption purely through its confirmed/pending/ unconfirmed flags rather than the persisted epoch. With no in-session send, all three are false and the caption is idle (nothing shown). Extract the mapping to a pure, public alarmStatusCaption() and cover it with regression tests driven by the real AlarmConfirmation transitions.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe Sleep Coach alarm caption now uses session-scoped alarm flags rather than a persisted alarm epoch. Tests cover idle, pending, unconfirmed, confirmed, disabled, and precedence states. ChangesAlarm caption flow
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On the Sleep tab, the caption under Set band alarm read "Alarm sent, waiting for the strap to confirm." on a fresh open, even when the user never tapped the button this session.
Root cause
The caption fell through to the pending/awaiting text whenever a persisted
alarmEpochexisted. That epoch is restored fromSharedPreferenceson launch (an alarm set in a previous session), but the strap-confirmation state machine (AlarmConfirmation) is session-scoped and records no SET on a cold open. So the fallthrough fired the "awaiting confirmation" caption with no user action.Fix
Route the caption purely through the session-scoped confirmation flags (
alarmConfirmed/alarmPending/alarmUnconfirmed) rather than the persisted epoch. On a fresh launch all three are false, so the caption is idle (nothing shown). The persisted epoch is deliberately no longer an input.alarmStatusCaption({confirmed, pending, unconfirmed})so the "only speak after an in-session SET" rule is unit-testable.context.selecttuple to(alarmConfirmed, alarmPending, alarmUnconfirmed)— exactly the fields the caption reads. The grace timer'snotifyListeners()flipsalarmPendingtrue→false, changing the tuple, so the pending→unconfirmed transition still triggers a rebuild.test/sleep_alarm_caption_test.dartcovering the mapping and driving the realAlarmConfirmationtransitions (fresh session → no caption; SET → pending → unconfirmed; event 56 → confirmed; disable → idle).Scope
UI caption only. Does not touch the BLE alarm delivery path (tracked separately as #119).
Closes #118
Summary by CodeRabbit
Bug Fixes
Tests