Harden Netty request-timeout tests against JVM stalls - #5549
Merged
Merged
Conversation
The "503, not 408" and "metrics when a request times out" tests made the server logic sleep for 2x the 1s request timeout. On CI a ~2.4s whole-JVM stall let the logic finish before the timeout task ran, so the server answered 200 instead of 503 (master run 36243258343). The logic now blocks on a latch that the test releases only after the client has read the timeout response, so the timeout always fires first. The tests also run about 1s faster.
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.
Fixes a flaky test introduced in #5466 (seen on master in run 36243258343).
The "respond with status 503, not 408" test and the "properly update metrics when a request times out" test made the server logic
Thread.sleepfor 2x the 1s request timeout. That leaves a 1s margin. On CI, a ~2.4s whole-JVM stall (visible as a gap in all suites' output) delayed both the timeout task and the sleeping logic. When the JVM resumed, the logic completed first, the 200 was written, and the timeout handler was removed. Result:List("HTTP/1.1 200 OK", "HTTP/1.1 200 OK")instead of200, 503.Now the logic blocks on a latch that is released only after the client has read the timeout response. The timeout always fires first, however long the JVM is stalled. The latch wait is bounded, so a failing test doesn't leave a blocked thread behind.
Side effect: both tests are about 1s faster, since nothing sleeps anymore.
Verified locally by freezing the sbt JVM (
SIGSTOP) for 2.5s right after the test server binds: passes 3/3 with this change.🤖 Generated with Claude Code