feat(httpnet): dedupe traffic to shared gateways - #1151
Draft
lidel wants to merge 2 commits into
Draft
Conversation
Codecov Report❌ Patch coverage is @@ Coverage Diff @@
## main #1151 +/- ##
==========================================
+ Coverage 64.18% 64.53% +0.34%
==========================================
Files 269 270 +1
Lines 27193 27393 +200
==========================================
+ Hits 17455 17678 +223
+ Misses 8024 8001 -23
Partials 1714 1714
... and 11 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Delegated routing routinely returns several peer IDs for one HTTP gateway. Bitswap creates one MessageQueue per peer ID, so a broadcast want for one CID becomes N identical requests against the same upstream. Concurrent requests that agree on (scheme, host, SNI, method, CID) now share a single round trip via a small singleflight tracker; each waiter still runs its own response handling, so per-peer cooldowns, latency estimates and bitswap accounting match what N separate requests would have produced. - inflight.go: singleflight tracker; keys distinguish every field that changes the upstream response; no result caching (coalescing applies only while a request is in flight); deferred cleanup so a panicking leader cannot wedge waiters - msg_sender.go: tryURL split into executeRequest (leader, one wire round trip, wire metrics) and handleResponse (per waiter); stats count logical messages per peer, wire metrics stay with the leader
N peer IDs resolving to one HTTP endpoint previously kept N copies of every error budget and re-proved the same gateway N times. Endpoint state now lives in one refcounted registry keyed by (scheme, host, SNI), shared by every peer using the endpoint, and throttling responses are treated as "wait", not "broken". - endpoint_tracker.go replaces the per-peer error tracker: probe method and round trip (Connect skips the probe for endpoints proven by another connected peer, inheriting HEAD support and the latency seed), shared server-error breaker, shared client-error counts, headerless-throttle streak; state drops when the last peer disconnects - breaker: one wire-level error charges the shared counter once no matter how many coalesced waiters observed it; any 200/404 resets it; a tripped endpoint is re-probed on Connect instead of inherited, and a successful probe forgives the errors - throttle (429/502/503/504): never charges the breaker and never disconnects; wants during the cooldown resolve as DONT_HAVE with no HTTP traffic and stay neutral toward the client-error threshold; without Retry-After the fallback backoff doubles per consecutive throttle up to DefaultMaxBackoff - senders snapshot the capped cooldown deadline instead of the raw Retry-After date, so one response cannot pause a sender beyond DefaultMaxBackoff - DefaultMaxRetries is now 3 (was 1): the counter it gates is shared per endpoint, so senders must agree on one threshold; 3 matches the budget bitswap's MessageQueue already used - Connect and DisconnectFrom serialize per peer, so endpoint registration cannot interleave with release
lidel
force-pushed
the
feat/httpnet-host-dedup
branch
from
August 18, 2026 16:14
eac3972 to
bd9deca
Compare
lidel
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Delegated routing routinely returns several peer IDs for one HTTP gateway. Bitswap keeps one MessageQueue per peer ID, so a single broadcast want becomes N identical requests, N
Connectprobes, and N separate error budgets against the same upstream. A single 429 also still escalates to a disconnect, and recovery waits on provider re-discovery.Fix
Retry-After1, wants during the window resolve as DONT_HAVE with zero HTTP traffic, and requests resume when it lapses; throttles without the header back off exponentially up toDefaultMaxBackoffDefaultMaxRetriesis now 3, matching the MessageQueue budget: senders sharing one breaker counter must agree on the thresholdBuilds on #1205. Out of scope: no bitswap-core or routing changes; peer IDs stay individually connected and addressable.
Before ramping:
Retry-AfterwindowsFootnotes
Path Gateway spec, Retry-After response header: gateways SHOULD return Retry-After with 429, 503 and 504. RFC 9110, section 10.2.3: Retry-After indicates how long to wait before a follow-up request. ↩