fix: allow dismissing an alarm that was deleted while ringing#470
Closed
MiMoHo wants to merge 1 commit into
Closed
fix: allow dismissing an alarm that was deleted while ringing#470MiMoHo wants to merge 1 commit into
MiMoHo wants to merge 1 commit into
Conversation
AlarmService.onStartCommand looked up the alarm in the DB up front and bailed out via stopSelfIfIdle() whenever it was missing. When an alarm is deleted while ringing, that lookup returns null, so ACTION_STOP_ALARM never reached stopActiveAlarm() and the alarm kept sounding with no way to dismiss or snooze it. Only the START path needs the alarm object; the STOP path only compares the id against the active alarm. Move the DB lookup (and null guard) into the ACTION_START_ALARM branch so a deleted alarm can still be stopped by id. Fixes FossifyOrg#406.
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.
Type of change(s)
What changed and why
AlarmService.onStartCommandlooked up the alarm in the database up front and, whenever the record was missing, bailed out viastopSelfIfIdle()and returnedSTART_NOT_STICKY. When an alarm is deleted while it is ringing (AlarmsAdapter.deleteItems()callsdbHelper.deleteAlarms(...)and postsAlarmEvent.Refreshbut never stops the service), that lookup returnsnull. Every dismiss / snooze / silence path funnels throughAlarmController->ACTION_STOP_ALARM->onStartCommand, so the null guard swallowed the stop request:stopActiveAlarm(alarmId)was never reached andstopSelfIfIdle()did nothing becauseactiveAlarmwas still set. The result was an alarm that keeps sounding with no way to dismiss or snooze it.Only the START path actually needs the alarm object; the STOP path merely compares the id against the currently active alarm. This moves the DB lookup and its null guard into the
ACTION_START_ALARMbranch, leavingACTION_STOP_ALARMable to stop a ringing alarm by id even after its DB row is gone. Behavior for the start path is unchanged.Tests performed
detekt,lint, unit tests and the build all pass locally (CI-equivalent).AlarmServicenow null-guardsgetAlarmWithId(alarmId)inside theACTION_START_ALARMbranch so a still-ringing alarm that was deleted from the DB can be dismissed instead of leaving the service stuck. This is a defensive null check with a clear, contained effect.Closes the following issue(s)
Checklist
CHANGELOG.md(if applicable).Coded with Opus 4.8 ultracode.