Skip to content

Sync internal 2026-05-15#879

Merged
drcaramelsyrup merged 12 commits into
mainfrom
bleeper-ewang-5281b97daa3213287999fb97c2a5de57ae565011
May 15, 2026
Merged

Sync internal 2026-05-15#879
drcaramelsyrup merged 12 commits into
mainfrom
bleeper-ewang-5281b97daa3213287999fb97c2a5de57ae565011

Conversation

@drcaramelsyrup
Copy link
Copy Markdown
Collaborator

No description provided.

icrutche and others added 12 commits April 20, 2026 12:12
Includes-commit: 875e4d9
Replicated-from: #858
Signed-off-by: Shane Utt <shaneutt@linux.com>
The test connects to 240.0.0.1 (reserved) while bound to localhost and
asserts the error is ConnectError or ConnectTimedout. On macOS and some
CI runners the kernel returns ENETUNREACH immediately, which maps to
ConnectNoRoute. Accept that as a valid outcome.

This is the same class of fix applied to test_conn_timeout and
test_tls_connect_timeout_supersedes_total in 542129f.
The old loop used `tokio::select!` with a `poll_closed` path that bailed
as soon as the shutdown signal fired. RFC 9113 §6.8 says we have to
process streams below the final last_stream_id. We weren't doing that.

Now we call `graceful_shutdown` on the connection, but streams that were
already in the buffer or have a lower stream number get surfaced and
dispatched normally. The loop exits once the codec flushes the closing
GOAWAY.

This also pulls the accept loop out of `apps/mod.rs` so that it's more
easily testable and usable from a test environment.
This is a trivially simple way to drive toward uniform weights between
LRU shards if they are unbalanced.
This option is then passed to daemonize as the child process immediately
runs chdir.
## Problem

`test_upload_connection_die` fails reliably in CI on both arm64 and x86. The test sends a 15MB upload to an nginx origin that immediately responds with 200, then kills the connection after 1s.

Under CI load, the 15MB upload takes longer than 1s. When nginx sends the TCP RST, it discards the buffered 200 response (per TCP protocol semantics). The proxy sees an upstream error and resets the client connection, causing the test to fail with `ConnectionReset`.

This is not a test bug — the proxy does not reliably forward early responses while still writing the request body upstream. The `select!` loop in `proxy_handle_upstream` is blocked on `send_body_to1` and cannot read the response concurrently.

## Fix

Mark the test as `#[ignore]` with a detailed comment explaining the root cause.
Implement the same proxy task API functionality for subrequest server sessions as HTTP/1.
Also fix the regular subrequest header write path so upgrade state is only marked after the 101 task is sent.
Creates ListenerConfig to hold this new config and allow for future
extensibility.
@drcaramelsyrup drcaramelsyrup merged commit c0845a8 into main May 15, 2026
9 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants