Fix a race condition in NotificationComponent leading to duplicate notification #10628
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
The race is between
NotificationTimerHandler, which sends a reminder notificationafter a certain inverval during problem states and
SendNotificationsHandlerwhichsends out the notifications on state changes.
When the timer handler runs just before a state change triggers a notification, the
timer handler might pick up that state-change before the send notification handler
can set its no_more_notifications flag. In that case a "reminder" notification will
be sent out before the initial one, and despite
interval = 0on the notificationobject.
Solution?
The trivial solution here is to never attempt to send a reminder if
interval <= 0and not wait for the no_more_notifications flag. I'm not entirely sure if there are any negative consequences to that because I don't understand what this flag is even supposed to do. It seems it only gets set in case ofinterval <= 0and only ever used in this one place. I can think of many valid reasons to want to turn off reminders under certain conditions for a while, but this doesn't even do that, since it was an&&-condition, not an||(which it is in the current state of this PR).Fixes #10623.