BB-830: fix notification config write race that silently drops events - #2786
BB-830: fix notification config write race that silently drops events#2786tcarmet wants to merge 2 commits into
Conversation
Hello tcarmet,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Codecov Report❌ Patch coverage is
Additional details and impacted files
... and 4 files with indirect coverage changes
@@ Coverage Diff @@
## development/9.3 #2786 +/- ##
===================================================
- Coverage 74.54% 74.47% -0.07%
===================================================
Files 199 199
Lines 13622 13629 +7
===================================================
- Hits 10154 10150 -4
- Misses 3458 3469 +11
Partials 10 10
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
cee4a21 to
f743a25
Compare
dc3449f to
18d93f6
Compare
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command: Alternatively, the |
18d93f6 to
cc18f26
Compare
Cover the idempotent create-or-update write and the listener-level retry of a transient write failure.
The per-bucket notification config write used a check-then-act sequence (exists, create-if-missing, setData). These calls are not atomic, so setData could fail with NO_NODE; the error was then logged and swallowed with no retry, permanently losing the bucket's configuration. The notification queue processor sources configs exclusively from zookeeper, so it then silently dropped every event for that bucket. Make the write idempotent (setData, creating the node only if it is missing) and retry the whole write with exponential backoff at the listener level, surfacing the error if every attempt fails rather than swallowing it.
cc18f26 to
ccb6f72
Compare
Bucket notification events could be silently and permanently lost for a bucket whenever the one-time write of its notification configuration to Zookeeper lost a race and failed, because the delivery path treats a missing configuration as "nothing to deliver" and drops every event for that bucket without a trace. This change makes that configuration write resilient so a transient failure no longer strands a bucket's notifications, and surfaces the previously silent drop in the logs. The race was found through intermittent failures of the bucket-notification end-to-end suite in CI (BB-830).