Merged
Conversation
…st XPASSes on a fresh main run PR #733 (#712) left the marker in place because no windows-latest CI evidence existed at review time. A fresh main-based run since then (commit 5657b01, run 35457414864) shows test_the_real_hook_traces_past_the_bootstrap passing plainly on all four windows-latest legs, independent of that PR's own run -- the re-derivation #690 asked for before trusting a strict=False XPASS as permanent. Closes #690 for real. Co-Authored-By: Max <noreply>
…es is gone Self-review (Explore) flagged that changelog.d/712.fixed.md still asserted "the xfail... stays in place, strict=False, until a real windows-latest run confirms" -- true when written, false as of the previous commit in this same branch, which removes that exact marker. Both fragments are still unreleased, so the fold into CHANGELOG.md would otherwise ship a contradiction. Appends a short follow-up note rather than editing the original claim, matching the fragment's own existing "Follow-up:" convention. Co-Authored-By: Max <noreply>
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
1 participant
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.
Closes #736
Closes #690
What
Removes the
xfail(strict=False, raises=AssertionError)marker ontest_the_real_hook_traces_past_the_bootstrapintests/test_trace_not_swallowed_690.py, now that the XPASS it was waiting on has been re-derived as stable rather than assumed permanent from a single observation.Why
#712's own fix (PR #733, merged as
5657b01) flipped this test to XPASS on all four windows-latest legs in that PR's own CI run, but the marker was deliberately left in place -- no Windows runner was available to the author or reviewer to confirm it locally, so confirmation was explicitly deferred to "the next windows-latest CI run" (per #736's own filing, quoting PR #733's body and review).That confirmation has now happened, independent of the PR run that first observed the XPASS: a fresh
main-based CI run (commit5657b01, run35457414864) shows1188 passed, 1461 skipped, 1 xpassedwith zero failures on each of the four windows-latest legs (Python 3.9, 3.10, 3.11, 3.12), pulled and verified individually. This is exactly the re-derivation #690's own comment thread and #736's own issue body ask for before treating astrict=FalseXPASS as permanently stable.#690's own reopening comment states this closes it "for real" once the marker is gone and the test runs as a plain pass on windows-latest -- both are now true.
Review
A concurrent self-review (Explore + oss:auditor) found one adjacent issue:
changelog.d/712.fixed.md, an older still-unreleased fragment, asserted the marker "stays in place" -- true when written, false once this PR's first commit removes it. Fixed with a follow-up note in the same fragment (matching its own existing "Follow-up:" convention) rather than editing the original claim.Testing
python3 -m pytest tests/test_trace_not_swallowed_690.py -q-> 10 passed, 1 skipped (unrelated environment-dependent skip), 0 failed. This is a metadata removal, not a behavior change, so there is no red-then-green cycle to show; the marker's own win32 condition never fires on this session's platform (macOS) regardless.Not filed
A repo-wide sweep for other strict=False xfail markers deserving the same re-derivation treatment is a low-confidence suggestion, not filed here; the reviewer that raised it did not check whether the tracker already has one open.
[AI-generated]