🧪 test(storage): share one capture subscriber - #2191
Open
gaborbernat wants to merge 1 commit into
Open
Conversation
The three webhook queue-scan cases assert on captured log output, and one of them failed on some runs and not others, a different case each time, with the count of the cleanup warning reading zero on an unchanged tree. A callsite decides its interest the first time any thread executes it, and every thread reads that decision afterwards. While one dispatcher is alive, tracing resolves that question against the registering thread's own default rather than the registry, so a thread holding no subscriber resolves it against nothing, caches never, and silences the callsite for the tests asserting on it. A subscriber that lives only as long as one test is absent whenever a neighbour asks first. One subscriber for the binary cannot be the one missing at that moment, and routing by thread keeps each case reading only its own events. Serialising the cases would have hidden the interleaving rather than removing it, and the assertion stays as it was: one warning across two scans, which is what proves the second scan found nothing left to clean. The new test drives the interleaving rather than waiting for it. A thread with no subscriber reaches a callsite first, and the event a subscribed thread raises there still lands in its capture. With a per-test subscriber that capture comes back empty.
gaborbernat
force-pushed
the
fix/webhook-capture-flake-2188
branch
from
September 4, 2026 11:13
95da23e to
0984a82
Compare
Merging this PR will not alter performance
Comparing Footnotes
|
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.
test_webhook_queue_scan_skips_and_cleans_damaged_rowsfailed on some runs and not others, a different one of its three cases each time, on an unchanged tree. The count of the cleanup warning came back as zero, and the scan does emit it on every pass that finds damage, so something dropped the event on the way rather than the scan skipping it.A callsite decides its interest the first time any thread executes it, and every thread reads that decision from then on. 🔍 While one dispatcher is alive,
tracingresolves that question against the registering thread's own default rather than against the registry, so a thread holding no subscriber resolves it against nothing, cachesInterest::never(), and silences the callsite for whichever case was asserting on it. A subscriber that lives only as long as one test is absent whenever a neighbour asks first, and which case loses that race is what varied between runs.One subscriber for the whole binary cannot be the one missing at that moment. Events route to a capture belonging to the thread that raised them, so the cases still read only their own output while sharing the decision each callsite makes once. Serialising them would have hidden the interleaving rather than removing it, and it would leave the next test that captures logs in this crate to rediscover the same thing.
The assertion holds as it was, one warning across two scans, which is what proves the second scan found nothing left to clean. Nothing in
WebhookQueueCleanup::logchanged.The new test drives the interleaving rather than waiting for it to come around. A thread holding no subscriber reaches a callsite first, and the event a subscribed thread raises at that callsite still reaches its capture. Swapping the shared subscriber back for a per-test one makes that capture come back empty, which is the failure this fixes.
Closes #2188