Repository navigation
test: wait for the Sentry scrubbers before closing in the log and span scrub tests - #216
Merged
Merged
Conversation
…umber of event turns Sentry 10.1.0 adds the device contexts to a log or a streamed span before its scrubber runs, and on Linux that runs cat /proc/meminfo as a subprocess. One pumpEventQueue() does not wait for a subprocess, so under CI load Sentry.close flushed an empty buffer and the log test saw no log item. The tests now wait until the scrubber has returned, then drain the remaining microtasks before closing. The assertions are unchanged.
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.
Main CI has been red since 71069cf on the Sentry log scrub test.
Cause: Sentry 10.1.0 adds the device contexts to a log or a streamed span before its scrubber runs, and on Linux that spawns `cat /proc/meminfo`. One `pumpEventQueue()` does not wait for a subprocess, so `Sentry.close` flushed an empty buffer.
The green cd7a1aa and red 71069cf trees are identical, so the flip came from runner timing.
Reproduced first: a `cat` on PATH that sleeps 0.2 s fails the log test and the streamed span test on every run, and 6 busy loops pinned to one CPU fail the log test 1 run in 10.
The tests now wait until the scrubber has returned, then drain the remaining microtasks and close. The assertions are unchanged.
With the fix the file passes with a 2 s `cat`, and 50 runs in a row under load all pass. The full local suite passes (4898 tests).
Closes #215