Wasmtime GitHub notifications bot (Oct 05 2026 at 14:10): Wasmtime GitHub notifications bot (Oct 05 2026 at 14:10):adamrk requested rvolosatovs for a review on PR #14535.
Wasmtime GitHub notifications bot (Oct 05 2026 at 14:10):adamrk requested wasmtime-wasi-reviewers for a review on PR #14535.
Wasmtime GitHub notifications bot (Oct 05 2026 at 14:10):adamrk requested pchickey for a review on PR #14535.
Wasmtime GitHub notifications bot (Oct 05 2026 at 14:10):adamrk requested wasmtime-core-reviewers for a review on PR #14535.
Wasmtime GitHub notifications bot (Oct 05 2026 at 14:10):adamrk opened PR #14535 from adamrk:abk/resolve-http-future-earlier to bytecodealliance:main:
Resolve the transmission future of sendnig an http request as soon as headers have been received for the response. The previous logic would wait to check that the connection was gracefully closed, but that could cause deadlocks or hangs if the client waits for that future to resolve before reading the response body.
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.mdPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Oct 05 2026 at 18:50):adamrk updated PR #14535.
Wasmtime GitHub notifications bot (Oct 05 2026 at 19:53)::memo: rvolosatovs submitted PR review:
I don't think that resolving the transmit future eagerly after receiving the response headers is correct, instead IMO the transmit future should be resolved when either:
- I/O future resolves to error
- Guest body reached the end (in
poll_frame)This way there is still ultimately a race condition between the last body chunk being handed over to hyper and the kernel accepting the bytes, but that's probably the best we can do right now
Wasmtime GitHub notifications bot (Oct 05 2026 at 19:53)::speech_balloon: rvolosatovs created PR review comment:
I don't think this is true. The response headers could be sent before the request body was transmitted.
This behavior would introduce a silent failure in case kernel returned an error when bytes are written on the underlying socket
Wasmtime GitHub notifications bot (Oct 05 2026 at 19:53)::speech_balloon: rvolosatovs created PR review comment:
In case response headers are received on L128, the transmit future would resolve to
Ok(()), whereas thesenditself would return an error, which does not seem like the right behavior
Wasmtime GitHub notifications bot (Oct 05 2026 at 19:57)::memo: rvolosatovs submitted PR review:
I don't think that resolving the transmit future eagerly after receiving the response headers is correct, instead IMO the transmit future should be resolved when either:
- Guest body reached the end (in
poll_frame)- I/O future resolves (if it resolves to success before all guest body bytes were sent, the transmit future should resolve to error)
This way there is still ultimately a race condition between the last body chunk being handed over to hyper and the kernel accepting the bytes, but that's probably the best we can do right now
Wasmtime GitHub notifications bot (Oct 05 2026 at 20:00):rvolosatovs commented on PR #14535:
The previous logic would wait to check that the connection was gracefully closed, but that could cause deadlocks or hangs if the client waits for that future to resolve before reading the response body.
this is expected behavior IMO, although I find it hard to come up with a use case for awaiting the request transmission future before handling the response, I'd expect most applications to await the request transmit and response receipt concurrently (e.g. using
join!in Rust)
Wasmtime GitHub notifications bot (Oct 05 2026 at 20:02):rvolosatovs edited a comment on PR #14535:
The previous logic would wait to check that the connection was gracefully closed, but that could cause deadlocks or hangs if the client waits for that future to resolve before reading the response body.
this is expected behavior IMO, although I find it hard to come up with a use case for awaiting the request transmission future before handling the response, I'd expect applications to either:
- await the request transmit and response receipt concurrently (e.g. using
join!in Rust)- simply ignore the transmit future
Wasmtime GitHub notifications bot (Oct 05 2026 at 20:29):adamrk commented on PR #14535:
this is expected behavior IMO, although I find it hard to come up with a use case for awaiting the request transmission future before handling the response, I'd expect applications to either:
- await the request transmit and response receipt concurrently (e.g. using join! in Rust)
- simply ignore the transmit futureYeah, that's a good point.
Wasmtime GitHub notifications bot (Oct 06 2026 at 14:12)::cross_mark: adamrk closed without merge PR #14535.
Wasmtime GitHub notifications bot (Oct 06 2026 at 14:12):adamrk commented on PR #14535:
You're right @rvolosatovs - I'll close this.
Last updated: Oct 11 2026 at 04:10 UTC