Description
Found while end-to-end testing #444: the elimination score is penalized only by the pending-latency signal — update-gateway-score with a terminal failure status maps to PenaliseSrv3 (SR-v3 windows only, should_update_gateway_score = false), while the elimination key is penalized only when a transaction is reported still pending (PENDING_VBV / STARTED) within the SR-v3 latency threshold of creation.
Hyperswitch's gateway-score update fires only when the payment intent reaches a terminal state, so it never reports pending. On the pure Hyperswitch path, elimination scores therefore stay at 1.0 forever, and elimination-based demotion (including the veto for pinned preferred connectors) rests only on scheduled/global outage configuration. A connector whose success rate collapses while still answering quickly with terminal failures is never demoted.
This predates the preferred-connector work — it affects all elimination usage on the open-router path — but pinned routing makes the gap more visible since elimination is the pin's only health veto.
Options
- Decision Engine also penalizes the elimination score on terminal failures (possibly only when the request carried
eliminationEnabled: true), or
- Hyperswitch reports pending states (from webhooks / payments-sync of in-progress payments) so the existing latency-based signal works, or
- both, with distinct penalty weights.
Needs a product/architecture call on which signal should drive elimination for open-router deployments.
🤖 Generated with Claude Code
Description
Found while end-to-end testing #444: the elimination score is penalized only by the pending-latency signal —
update-gateway-scorewith a terminal failure status maps toPenaliseSrv3(SR-v3 windows only,should_update_gateway_score = false), while the elimination key is penalized only when a transaction is reported still pending (PENDING_VBV/STARTED) within the SR-v3 latency threshold of creation.Hyperswitch's gateway-score update fires only when the payment intent reaches a terminal state, so it never reports pending. On the pure Hyperswitch path, elimination scores therefore stay at 1.0 forever, and elimination-based demotion (including the veto for pinned preferred connectors) rests only on scheduled/global outage configuration. A connector whose success rate collapses while still answering quickly with terminal failures is never demoted.
This predates the preferred-connector work — it affects all elimination usage on the open-router path — but pinned routing makes the gap more visible since elimination is the pin's only health veto.
Options
eliminationEnabled: true), orNeeds a product/architecture call on which signal should drive elimination for open-router deployments.
🤖 Generated with Claude Code