dicej opened PR #13933 from dicej:p2-send-to-closed-receiver to bytecodealliance:main:
This addresses a failing Tokio test where receiving on a connected socket whose remote has disconnected after sending should return an error immediately.
Note that I've implemented the simplest thing that could work, possibly at a cost to performance. A more sophisticated alternative could be to update the
Pollableimpl forIncomingDatagramStreamto check thetokio::io::Readyfor "error" readiness and only calltokio::net::UdpSocket::take_errorin that case.<!--
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 ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
dicej requested pchickey for a review on PR #13933.
dicej requested wasmtime-wasi-reviewers for a review on PR #13933.
dicej requested wasmtime-core-reviewers for a review on PR #13933.
:thumbs_up: alexcrichton submitted PR review.
alexcrichton added PR #13933 check for and return WASIp2 UDP socket errors when receiving to the merge queue.
github-merge-queue[bot] removed PR #13933 check for and return WASIp2 UDP socket errors when receiving from the merge queue.
github-actions[bot] added the label wasi on PR #13933.
Ah, the Windows test failures are not unexpected, given https://github.com/tokio-rs/tokio/blob/bc0933ccffb62e010d3ccb497abc22cec2e73f54/tokio/tests/udp.rs#L79-L85
I'll update the code to turn
ConnectionResetintoConnectionRefusedon Windows in the host implementation ofudp-socket.receiveunless someone has a better idea.
Or maybe just update the tests to match what Tokio does? I don't know how important it is to have consistent behavior across host platforms for a situation like this.
dicej updated PR #13933.
dicej has enabled auto merge for PR #13933.
dicej added PR #13933 check for and return WASIp2 UDP socket errors when receiving to the merge queue.
alexcrichton commented on PR #13933:
Yeah I think updating to expect a number of error codes is fine
github-merge-queue[bot] removed PR #13933 check for and return WASIp2 UDP socket errors when receiving from the merge queue.
Ugh, now the MSVC builds pass but the MinGW one fails. Wonder if I'm going to need to borrow my wife's Windows laptop :sob:
badeend commented on PR #13933:
@dicej Does the problem persist after yesterday's changes?
@badeend I'll rebase and find out when I get a chance.
dicej updated PR #13933.
dicej added PR #13933 check for and return WASIp2 UDP socket errors when receiving to the merge queue.
github-merge-queue[bot] removed PR #13933 check for and return WASIp2 UDP socket errors when receiving from the merge queue.
@badeend looks like your changes are at least as good as mine as far as making the new tests pass, but we're still seeing timeouts for the MinGW build (and a new C API failure on Windows, the cause of which is not obvious to me). I'll see if I can reproduce and debug when I get a chance (and access to a Windows machine).
dicej updated PR #13933.
dicej updated PR #13933.
dicej has enabled auto merge for PR #13933.
dicej added PR #13933 check for and return WASIp2 UDP socket errors when receiving to the merge queue.
github-merge-queue[bot] removed PR #13933 check for and return WASIp2 UDP socket errors when receiving from the merge queue.
dicej added PR #13933 check for and return WASIp2 UDP socket errors when receiving to the merge queue.
:check: dicej merged PR #13933.
dicej removed PR #13933 check for and return WASIp2 UDP socket errors when receiving from the merge queue.
Last updated: Jul 29 2026 at 05:03 UTC