New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: TestTransportPersistConnReadLoopEOF
failures with Connection reset by peer
on wasip1
#64317
Comments
Ah, I think this is related to #30938. https://go.dev/cl/379554 changed the propagation of |
This comment was marked as resolved.
This comment was marked as resolved.
Hmm. I wonder if we just need to crank up |
Change https://go.dev/cl/558595 mentions this issue: |
Change https://go.dev/cl/558915 mentions this issue: |
…opEOF Flakes in #64317 are a result of a race where the server shutdown schedules ahead of the client read loop. Normal network latency usually hides this, but wasm's net_fake.go has very low latency. Explicitly allow the results of this race in the test. For #64317. Change-Id: I9c2572fb44643762fe3f3d7cb133d7e7a8a47881 Reviewed-on: https://go-review.googlesource.com/c/go/+/558595 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
…nections This mimics the apparent behavior of writes on linux/amd64, in which a write on an already-closed connection silently succeeds — even if the connection has already been closed by the remote end — provided that the packet fits in the kernel's send buffer. I tested this by patching in CL 557437 and running the test on js/wasm and wasip1/wasm locally. Fixes golang#64317. Change-Id: I43f6a89e5059115cb61e4ffc33a8371057cb67a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/558915 Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…opEOF Flakes in golang#64317 are a result of a race where the server shutdown schedules ahead of the client read loop. Normal network latency usually hides this, but wasm's net_fake.go has very low latency. Explicitly allow the results of this race in the test. For golang#64317. Change-Id: I9c2572fb44643762fe3f3d7cb133d7e7a8a47881 Reviewed-on: https://go-review.googlesource.com/c/go/+/558595 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
Examples:
See previously:
(CC @neild @golang/wasm)
The text was updated successfully, but these errors were encountered: