test(logging): Fix flaky test_logging_captured_warnings - #6824
Merged
ericapisani merged 1 commit intoJul 14, 2026
Merged
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
The test asserted the total recwarn count was exactly 1, but recwarn records every warning emitted during the test. In the full suite a stray warning leaked from another module could add a second entry, making the assertion flaky depending on test order. Filter recwarn for the specific "third" warning the test cares about instead of asserting on the total count. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ericapisani
marked this pull request as ready for review
July 14, 2026 17:33
sl0thentr0py
approved these changes
Jul 14, 2026
Copy link
Copy Markdown
Contributor
Codecov Results 📊✅ 91185 passed | ⏭️ 6302 skipped | Total: 97487 | Pass Rate: 93.54% | Execution Time: 313m 46s 📊 Comparison with Base Branch
✨ No test changes detected All tests are passing successfully. ✅ Patch coverage is 100.00%. Project has 2445 uncovered lines. @@ Coverage Diff @@
## main #PR +/-##
==========================================
- Coverage 89.80% 89.77% -0.03%
==========================================
Files 193 193 —
Lines 23898 23898 —
Branches 8258 8258 —
==========================================
+ Hits 21461 21453 -8
- Misses 2437 2445 +8
- Partials 1353 1355 +2Generated by Codecov Action |
Sorry, something went wrong.
6 tasks
mgaligniana
pushed a commit
to mgaligniana/sentry-python
that referenced
this pull request
Aug 9, 2026
## Summary Fixes a flaky failure in `tests/integrations/logging/test_logging.py::test_logging_captured_warnings` seen in CI (`assert len(recwarn) == 1` failing with `assert 2 == 1`). ## Root cause The `recwarn` fixture records **every** warning emitted during the test. The test asserted the total count was exactly 1, which holds in isolation and in file order, but fails in the full `tests` suite when an unrelated warning leaks in from another module (warning filter/registry state is process-global). Whether it reproduces depends on test ordering. ## Fix Filter `recwarn` for the specific `"third"` warning the test actually cares about instead of asserting on the total count. This preserves the test's intent — verifying that `"third"` (emitted after `captureWarnings(False)`) is not captured by Sentry but surfaces as a normal warning — while being immune to stray warnings from other tests. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
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.
Summary
Fixes a flaky failure in tests/integrations/logging/test_logging.py::test_logging_captured_warnings seen in CI (assert len(recwarn) == 1 failing with assert 2 == 1).
Root cause
The recwarn fixture records every warning emitted during the test. The test asserted the total count was exactly 1, which holds in isolation and in file order, but fails in the full tests suite when an unrelated warning leaks in from another module (warning filter/registry state is process-global). Whether it reproduces depends on test ordering.
Fix
Filter recwarn for the specific "third" warning the test actually cares about instead of asserting on the total count. This preserves the test's intent — verifying that "third" (emitted after captureWarnings(False)) is not captured by Sentry but surfaces as a normal warning — while being immune to stray warnings from other tests.