wai http origin: a refusal ends cleanly, and origin_per_peer_limit waits for its state #657
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/origin-503-reset"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
wai http originended a refusal in a reset, andorigin_per_peer_limitfailed under load.The origin
It answered 503 and closed with the request unread, so the connection ended in a reset after the answer. Clients on Linux and macOS still read the 503, but one reading to the close then got an error. A refused request that wrote at once saw this 300 times in 300, on both systems. For a client past
--max-per-peeror--max-connections, the origin now stops sending and reads a little more before closing, which the 431 path already did. Both sharedrain_before_close.With this change, 300 of 300 refused requests on each system read the 503 and a clean close, both writing at once and 20 ms late. A refused connection's thread can now last up to about 1 s, bounded by the same limits as the 431 path.
The test
origin_per_peer_limitcould fail in three ways under load:It now retries an attempt overtaken and waits for each state, with a 30 s deadline and a read timeout that outlasts it. It also requires 200 refusals to read their 503 with no read error and no retry.
Verified
On a Linux build host, Rust 1.99.1:
origin_per_peer_limit: 12 of 12, and 49 of 50 with ten copies running at once. The one failure was those copies sharing a scratch folder (NotFound), which CI doesn't do.cli_http: 22 passed.refusal 0: ... ConnectionReset.The changelog entry is
wai/changes/2026-11-05-origin-refusal-ends-cleanly.md.🤖 Generated with Claude Code