fix(python): stop teardown test flaking on unrelated thread reaps#2208
Open
claude[bot] wants to merge 1 commit into
Open
fix(python): stop teardown test flaking on unrelated thread reaps#2208claude[bot] wants to merge 1 commit into
claude[bot] wants to merge 1 commit into
Conversation
test_threads_joined_deterministically_after_drop asserted an exact process-wide thread count and failed intermittently in the shrink direction (assert 13 == 14 here, assert 15 == 16 on main at 082447e), blocking unrelated PRs. Not a leak. tokio reaps idle blocking-pool threads on a 10 s timer, so a pytest session that ran async work earlier sheds an unrelated thread part-way through the churn loop. Measured: the count holds at 6 after an async workload and drops to 5 at exactly t=10.0 s. TM-PY-030 is about what a drop leaves behind, so the invariant is one-directional. Replaces the equality check with _assert_no_thread_growth(), matching what the sibling fd-churn test in the same file already did. A real leak compounds across the five iterations and still trips it. Adds two tests pinning the direction: an inflated baseline must pass, and growth must fail. Both fail against the old == form.
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
bashkit | 5ed0c54 | Commit Preview URL Branch Preview URL |
Jul 26 2026, 05:40 AM |
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.
What changed
test_threads_joined_deterministically_after_dropno longer asserts an exact process-wide thread count. The check is now_assert_no_thread_growth(baseline)— one-directional, matching what the siblingtest_fds_stable_across_tool_churnin the same file already did with<= baseline.Two tests pin the direction: an inflated baseline must pass, growth must still fail.
Why
The test failed intermittently and blocked unrelated PRs —
assert 13 == 14on #2206,assert 15 == 16onmainat082447e3(a dependabot actions bump). Note the direction: the observed count was below the baseline. Nothing leaked; a thread went away.The cause is tokio reaping idle blocking-pool threads on a 10 s timer. A pytest session that ran async work before this module sheds an unrelated thread part-way through the churn loop. Measured directly rather than guessed:
If
baselineis captured inside that window, the reap lands mid-loop and exact equality reports a defect that did not occur.TM-PY-030 is about what a drop leaves behind, and the process-wide count is not a single tool's to own. A genuine leak compounds across the five churn iterations and still pushes the count above the baseline, so leak detection is unchanged.
Before / After
The new tests discriminate — the same tests against the old
==form vs. the fix:Full Python suite, four consecutive runs:
just pre-prgreen, includingcargo vet.ruff checkandruff format --checkclean.Risk
knowledge/python-package.mdrecords the measurement and an explicit "do not re-tighten", so the equality check does not come back.Checklist
Generated by Claude Code