Repository navigation
fix(test): drain queued connections before HTTP observation stops - #4562
Open
ScriptedAlchemy wants to merge 1 commit into
Open
ScriptedAlchemy wants to merge 1 commit into
ScriptedAlchemy wants to merge 1 commit into
Conversation
The observer loop read the stop flag after accept() returned WouldBlock. A connection the action completed between that accept and the flag load was never counted, so a loaded runner saw 0 instead of 1. Read the flag before accept(): a WouldBlock after a set flag proves the backlog was already empty once the action returned. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
This branch has not been deployed
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.
Fixes #4561
Problem
cli_non_interactive_test::http_observation_counts_connections_and_releases_its_listener_on_unwindintermittently saw 0 accepted connections instead of 1 (PR #4534, run 40275017040).Root cause
The accept loop in
observe_http_connectionsread the stop flag afteraccept()returnedWouldBlock. A connection the action completed, followed by the stop signal, between thataccept()and the flag load was never counted.Fix
Read the stop flag before
accept(). AWouldBlockthat follows an already-set flag proves the backlog was empty after the action returned, so every completed connection is counted. The listener is still dropped when the observer thread returns, before observation returns, and a panicking action still unwinds through theStopHttpObservationguard. All four callers of the helper share the one loop. No sleeps or timeouts were added or changed.Verification
The race does not fire naturally on this macOS host. 200 runs under 54 busy loops (
--runs_per_test=200) passed 200/200 both before and after the fix. To prove the mechanism I injected a temporary 20 ms delay betweenaccept()and the flag decision (not committed):a completed connection must be observed, left: 0, right: 1(the CI failure verbatim).After removing the delay:
//crates/tracedecay-cli:core_cli_suite: 198 pass, 4 fail. The 4 failures areremote_cli_test::remote_*(error sending request for url (https://127.0.0.1:.../remote/enrollment)) and fail identically on unmodified origin/master on this host.bazel build --config=clippy //crates/tracedecay-cli/...is clean.🤖 Generated with Claude Code