Repository navigation
fix(http): await bounded connection teardown - #2
Conversation
|
Independent code review (agent Audited: five-second headers-only DELETE; dropping inner streams/POSTs before cleanup; original transport-error preservation; graceful inbound-response preservation, including cancellation during cleanup; at most one cleanup dispatch per admitted connection; metadata budget lease retained through cleanup; no automatic POST retry. Five loopback HTTP regressions cover these failure and shutdown paths. Local exact-head checks: HTTP suite 107 unit tests and 5 interoperability tests passed; strict all-targets/all-features HTTP clippy passed. Full repository recipe and remote checks are still pending. Cleanup remains best effort and does not guarantee remote deletion when cancellation interrupts DELETE. |
Summary
Restore connection teardown in the bounded HTTP client: graceful and error exits await a best-effort DELETE for an admitted connection ID. Teardown has a five-second deadline and does not consume response bodies.
Motivation
The bounded driver previously returned on graceful outgoing EOF without deleting the remote connection, unlike the legacy client. Callers awaiting transport completion could therefore leave initialized connections behind.
Technical details
A single-owner cleanup guard captures validated, budgeted connection metadata before reading the initialization body and retains its lease through teardown. Driver-owned streams and POSTs stop before DELETE begins, and cleanup failures do not replace the transport result.
Cancellation dispatches at most one best-effort cleanup task per connection if teardown has not started and a Tokio runtime is available. It can interrupt an already-started DELETE and never guarantees remote deletion. Accepted or uncertain POSTs are not retried.