You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: tag hedge relays separately so geography doesn't punish slow suppliers
The hedge race fan-out was double-counting in path_relays_total: both the
primary AND the hedge branch's relay completed and called RecordRelay with
request_type="normal", inflating the visible RPS for whichever endpoint
happens to be picked as hedge most often (typically the lowest-latency one).
Symptom observed on canary at 22m post-deploy of #512: rpcgate.xyz with 1
endpoint at 431 RPS while stakenodes.org with 21 endpoints averaged 7.7 RPS
per endpoint. Per-endpoint share was 17x off baseline despite uniform-random
tier-1 selection. The skew traced to (a) hedge metric double-count and (b)
hedge losers getting latency-penalty signals for slowness that only mattered
inside the race they already lost.
This change:
- Adds RelayTypeHedge metric constant
- Adds MarkAsHedge() to ProtocolRequestContext interface
- Hedge branch is tagged before HandleServiceRequest; protocol layer records
the relay under request_type="hedge" instead of "normal"
- Skips recordLatencyPenaltySignalsIfNeeded for hedge branches — far-from-
gateway endpoints no longer accumulate slow-response reputation penalties
for losing hedge races they only entered because of distance
- Reputation success/error signals still fire so endpoints get fair feedback
about whether they actually work
Dashboards filtering request_type="normal" by default now show fair primary-
traffic distribution. Operators can flip the variable to "hedge" to see the
backup-attempt side independently.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments