fix(trade): retry transient gateway failures on idempotent wait-polls#42
Merged
Conversation
Observed live 2026-06-11: a deposit's settlement loop made ~40 /trade/next
polls; a single 502 between Cloudflare and the origin aborted the CLI and
reported an already-completed deposit as failed.
post() now takes an opt-in retryTransient flag: 502/503/504 responses and
network-level fetch failures back off (2s/5s/10s) and retry. Only the pure
wait-polls ({tradeId, step} — no txHash/signature payload) opt in; send and
sign result posts are never replayed because the CLI cannot know whether the
server consumed the original before the connection died.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zuhwa
approved these changes
Jun 12, 2026
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
2 participants
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.
Bug
During a live Hyperliquid deposit on 2026-06-11, the settlement loop made ~40
/trade/nextpolls. One of them hit a transient 502 between Cloudflare and the origin (the request never reached the backend — confirmed in Railway logs), and the CLI threw fatally — reporting a deposit that had already completed on-chain as a failed trade, and leaving the server-side trade orphaned as active.Fix
post()gains an opt-inretryTransientflag: 502/503/504 responses and network-level fetch failures back off (2s → 5s → 10s) and retry instead of aborting.Scope is deliberately narrow: only pure wait-polls opt in (
{tradeId, step}with notxHash/signaturepayload — idempotent by construction). Send-result and sign-result posts are never replayed, because the CLI can't know whether the server consumed the original before the connection died.Companion server-side fix (settle HL deposits by the exchange ledger so the loop ends as soon as funds arrive): internal-trading-bot#18. Related: #41.
npm run typecheckpasses.🤖 Generated with Claude Code
Note
Medium Risk
Changes trade-loop HTTP behavior during long-running flows; scope is limited to idempotent wait polls, but incorrect retry on non-idempotent paths would be serious—those paths are explicitly excluded.
Overview
Fixes a case where a single transient 502/503/504 (or dropped connection) on
/trade/nextduring settlement wait polling could fail the whole trade even when on-chain work had already finished.post()now accepts an opt-inretryTransientflag that retries those gateway/network failures with 2s → 5s → 10s backoff (up to three delays). Only wait steps passretryTransient: true—payloads are just{tradeId, step}and treated as idempotent. Send and sign follow-ups still use a single attempt so the CLI does not replaytxHash/signatureposts when the server may have already processed them.Reviewed by Cursor Bugbot for commit 01aadc5. Bugbot is set up for automated code reviews on this repo. Configure here.