-
Notifications
You must be signed in to change notification settings - Fork 15
Correctness fixes: maxFee, 504 retries, key cache #238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
66e1195
Forward maxFee across submitWithFeeIncrease retries
CassioMG 6b5e82b
Bound submitTransaction 504 retries with exponential backoff
CassioMG 4593135
Clear KeyManager cache entry on removeKey
CassioMG ba3cb75
Use equal-jitter backoff so retry waits stay within the cap
CassioMG 4939bb2
Restore truthy maxFee guard to preserve maxFee: 0 semantics
CassioMG e7aba81
Document submitTransaction retry envelope and 504-exhausted state
CassioMG File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
504 retry semantics changed from unbounded to ~6 attempts / ~46s. The previous implementation retried recursively forever; this caps at
SUBMIT_504_MAX_RETRIES + 1attempts and then throws the last 504. Two follow-ups worth considering:Caller cascade:
submitWithFeeIncreasecatchessubmitTransactionerrors and only handlestx_too_late. A bubbled 504 hasgetResultCode(e) === '', so it rethrows immediately — even though the original transaction may still land on-chain. A naive caller that retries on its own will double-submit. Worth either documenting this in the JSDoc or special-casing 504 insubmitWithFeeIncrease.Jitter exceeds the documented cap (line 160):
cappedDelay = Math.min(BASE * 2**attempt, MAX)is clamped to 30s, but jitter (Math.random() * cappedDelay/2, up to 15s) is then added on top, giving ~45s waits on the final retries — 50% overSUBMIT_504_MAX_DELAY_MS. If the cap is meant to bound caller latency, apply jitter first andMath.minafter, or use full-jitter (Math.random() * cappedDelay).Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On 1 (caller cascade): you're right that an exhausted-504 bubbles through
submitWithFeeIncreaseunchanged, and the developer-experience concern stands. Documented in e7aba81 — the new JSDoc onsubmitTransactionexplicitly calls out that an exhausted-504 leaves the on-chain status indeterminate and that callers should poll the tx hash rather than resubmit blindly (and notes that resubmitting the same signed tx will fail withtx_bad_seqonce the original lands, so it's a DX problem rather than a fund-loss one — Stellar's sequence numbers prevent the double-submit you're concerned about).On 2 (jitter exceeds the cap): fixed in ba3cb75 — switched to equal-jitter (
cappedDelay/2 + Math.random() * cappedDelay/2), so sleeps now stay in[cap/2, cap]. Retains the herd-smoothing benefit with a deterministic progressive floor, and the namedSUBMIT_504_MAX_DELAY_MSactually bounds the wait now.