Repository navigation
docs(stickiness): a pinned request fails instead of failing over (MAG-2280, MAG-4123) - #77
Draft
Tomelia1999 wants to merge 2 commits into
Draft
Tomelia1999 wants to merge 2 commits into
Tomelia1999 wants to merge 2 commits into
Conversation
…-2280, MAG-4123) Three sentences promised that a pinned request falls over to the rest of the pool after an error. The router no longer does that: a request pinned by lava-select-provider or lava-stickiness is answered by its node or fails with that node's error, Lava-Retries 0, and the router neither retries nor hedges it elsewhere. The sticky-sessions page's "route to the session's node, or fail" now holds for errors and for the router's own freshness check too. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Tomelia1999
added a commit
to Magma-Devs/smart-router
that referenced
this pull request
Oct 25, 2026
…from another node (MAG-2280, MAG-4123) A request pinned with lava-select-provider or lava-stickiness is answered by the pinned upstream or fails with that upstream's error. The router no longer retries it, hedges it, or re-selects for it on another node, and no longer drops the pin when its own consistency gate rejects the pinned node. Three paths quietly served a pinned request from another node: - MAG-2280: the pinned node answered with a retryable error (a 429, say) and the retry batch dropped the pin (MAG-2228). For the head-then-fetch sequence lava-stickiness exists for, the fallback node was never checked to have reached the block, so the retry produced the very false gap the header was meant to prevent; and the pin stayed on the failing node for the next request. - MAG-4123: the pre-dispatch consistency gate judged the pinned node too far behind on a `latest` call, released it, and the resend ran selection without the pin: another node answered with Lava-Retries 0 and nothing in the reply said so. - The attempt window hedged a slow pinned request onto another node. Now the policy stops a pinned request after a node error and at the attempt window (DecisionInput.Pinned, reason "Pinned"); a selection error that names the pin stops the send stage at once (reason "PinnedProviderUnavailable") instead of after SendRelayAttempts resends; the consistency gate fails a pinned request with "pinned provider is too far behind the chain tip" instead of starting an unpinned retry; the pin resolver honours the headers on every attempt; and a sticky provider that already failed this request is refused like a named pin, not replaced. The session keeps its node through these failures. A node that keeps failing is still blocked by the health machinery, which invalidates the pin as before. Client-visible: a pinned request that used to be served by another node now returns the pinned node's error (or a router error for the consistency case) with Lava-Retries 0. The docs that promised the old failover are updated in Magma-Devs/docs#77. Tests: policy (pinned never retries, hedges or broadcasts; pin errors stop the send stage), relaycore helpers, the real state machine over the REST mock chain (node error ends on "Pinned" with one batch; a pin refusal ends on the first send), the gate's terminal error, and the sticky already-failed refusal. The hedge-accounting end-to-end test steered its first attempt with a pin; it now uses a fixed selection order, since a pinned request no longer hedges. Two relay_end goldens carry the new stop reason. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
8 of 12 tasks
Tomelia1999
added a commit
to Magma-Devs/smart-router
that referenced
this pull request
Oct 25, 2026
…from another node (MAG-2280, MAG-4123) A request pinned with lava-select-provider or lava-stickiness is answered by the pinned upstream or fails with that upstream's error. The router no longer retries it, hedges it, or re-selects for it on another node, and no longer drops the pin when its own consistency gate rejects the pinned node. Three paths quietly served a pinned request from another node: - MAG-2280: the pinned node answered with a retryable error (a 429, say) and the retry batch dropped the pin (MAG-2228). For the head-then-fetch sequence lava-stickiness exists for, the fallback node was never checked to have reached the block, so the retry produced the very false gap the header was meant to prevent; and the pin stayed on the failing node for the next request. - MAG-4123: the pre-dispatch consistency gate judged the pinned node too far behind on a `latest` call, released it, and the resend ran selection without the pin: another node answered with Lava-Retries 0 and nothing in the reply said so. - The attempt window hedged a slow pinned request onto another node. Now the policy stops a pinned request after a node error and at the attempt window (DecisionInput.Pinned, reason "Pinned"); a selection error that names the pin stops the send stage at once (reason "PinnedProviderUnavailable") instead of after SendRelayAttempts resends; the consistency gate fails a pinned request with "pinned provider is too far behind the chain tip" instead of starting an unpinned retry; the pin resolver honours the headers on every attempt; and a sticky provider that already failed this request is refused like a named pin, not replaced. The session keeps its node through these failures. A node that keeps failing is still blocked by the health machinery, which invalidates the pin as before. Client-visible: a pinned request that used to be served by another node now returns the pinned node's error (or a router error for the consistency case) with Lava-Retries 0. The docs that promised the old failover are updated in Magma-Devs/docs#77. Tests: policy (pinned never retries, hedges or broadcasts; pin errors stop the send stage), relaycore helpers, the real state machine over the REST mock chain (node error ends on "Pinned" with one batch; a pin refusal ends on the first send), the gate's terminal error, and the sticky already-failed refusal. The hedge-accounting end-to-end test steered its first attempt with a pin; it now uses a fixed selection order, since a pinned request no longer hedges. Two relay_end goldens carry the new stop reason. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The opt-in that keeps a pin to the first attempt: retries and hedges may go to other nodes, the session keeps its node. Directive table row, its own section with when (not) to use it, and pointers from the sticky-sessions Retry row and the retry page. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tomelia1999
added a commit
to Magma-Devs/smart-router
that referenced
this pull request
Oct 26, 2026
…from another node (MAG-2280, MAG-4123) A request pinned with lava-select-provider or lava-stickiness is answered by the pinned upstream or fails with that upstream's error. The router no longer retries it, hedges it, or re-selects for it on another node, and no longer drops the pin when its own consistency gate rejects the pinned node. Three paths quietly served a pinned request from another node: - MAG-2280: the pinned node answered with a retryable error (a 429, say) and the retry batch dropped the pin (MAG-2228). For the head-then-fetch sequence lava-stickiness exists for, the fallback node was never checked to have reached the block, so the retry produced the very false gap the header was meant to prevent; and the pin stayed on the failing node for the next request. - MAG-4123: the pre-dispatch consistency gate judged the pinned node too far behind on a `latest` call, released it, and the resend ran selection without the pin: another node answered with Lava-Retries 0 and nothing in the reply said so. - The attempt window hedged a slow pinned request onto another node. Now the policy stops a pinned request after a node error and at the attempt window (DecisionInput.Pinned, reason "Pinned"); a selection error that names the pin stops the send stage at once (reason "PinnedProviderUnavailable") instead of after SendRelayAttempts resends; the consistency gate fails a pinned request with "pinned provider is too far behind the chain tip" instead of starting an unpinned retry; the pin resolver honours the headers on every attempt; and a sticky provider that already failed this request is refused like a named pin, not replaced. The session keeps its node through these failures. A node that keeps failing is still blocked by the health machinery, which invalidates the pin as before. Client-visible: a pinned request that used to be served by another node now returns the pinned node's error (or a router error for the consistency case) with Lava-Retries 0. The docs that promised the old failover are updated in Magma-Devs/docs#77. Tests: policy (pinned never retries, hedges or broadcasts; pin errors stop the send stage), relaycore helpers, the real state machine over the REST mock chain (node error ends on "Pinned" with one batch; a pin refusal ends on the first send), the gate's terminal error, and the sticky already-failed refusal. The hedge-accounting end-to-end test steered its first attempt with a pin; it now uses a fixed selection order, since a pinned request no longer hedges. Two relay_end goldens carry the new stop reason. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This branch has not been deployed
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
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.
Docs follow-up to the router change for MAG-2280 and MAG-4123 (Magma-Devs/smart-router#578). Draft until that PR is in a release, since these pages describe shipped behaviour.
docs/configuration/sticky-sessions.md: the Retry row no longer says a retry goes to a different node. "What happens when the session cannot be honoured" now lists an error from the node and the router's own freshness check among the ways a sticky request fails, and says the session keeps its node through such a failure.docs/api/directives.md:lava-select-provideris described as a pin, not a preference, and the sentence "If it fails, failover policies still apply against the rest of the pool" is replaced by the new rule.docs/configuration/failover/retry.md: "Pinning to one node" no longer says retry kicks in on the rest of the pool.🤖 Generated with Claude Code