Repository navigation
Conversation
In streaming mode, post() armed a fresh per-leg deadline, but the explicit transport.connect() that WsmanClient.send() makes after a dropped connection reused the previous leg's deadline. After a pause longer than the inactivity timeout, that deadline had expired and the TCP connect and TLS handshake got a 1 ms budget, surfacing as a spurious "No response from the WinRM service" timeout. connect() now arms the per-leg deadline itself, and post() goes through connect(). The pollTimeout (shared absolute deadline) and blocking (no deadline) modes are unchanged. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
NassimBtk
changed the title
bertysentry
approved these changes
Oct 7, 2026
NassimBtk
deleted the
bugfix/issue-198-streaming-command-fails-with-a-spurious-timeout-when-reconnecting-after-an-idle-pause
branch
October 9, 2026 09:27
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
2 participants
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 #198
Problem
In streaming mode,
HttpTransport.post()set a fresh per-leg deadline before each request, but the explicittransport.connect()thatWsmanClient.send()makes after a dropped connection did not. It reused the deadline left by the previous leg.After a pause longer than the inactivity timeout (e.g. a slowly read
RemoteProcess, with the host dropping the idle keep-alive connection meanwhile), that deadline had already expired. The TCP connect and the TLS handshake then got the 1 ms floor and failed with aSocketTimeoutException, reported as No response from the WinRM service.Fix
HttpTransport.connect()sets the per-leg deadline itself whendeadlinePerLegis on, so an explicit reconnection is a leg of its own.post()now goes throughconnect(), so the deadline is set in one place only.pollTimeoutmode (one absolute deadline shared by all legs) and blocking mode (no deadline) are unchanged.This also makes the documented retry behavior true for streaming terminals: each connection attempt is bounded by that timeout (
timeouts-and-errors.md). Before the fix, a retried reconnection inherited the stale deadline too.Tests
HttpTransportDeadlineTest.aStreamingReconnectGetsAFreshDeadline: a fake TLS peer reads the ClientHello, waits 200 ms, then hangs up. After one streaming leg and a pause past its deadline,connect()must see the hang-up instead of timing out.SocketTimeoutException: Read timed out.mvn verify: 332 tests pass (9 skipped, the live tests). Checkstyle, PMD and SpotBugs report nothing.Note
Once #196 is merged as well, its extra
configureTimeouts(...)call after the best-effort Delete instartCommand()is probably redundant. Check before removing it: inpollTimeoutmode that call also resets the shared deadline.🤖 Generated with Claude Code