Fix/1763 settlement scheduler persist retry count - #1780
Merged
Olowodarey merged 3 commits intoAug 29, 2026
Merged
Conversation
Adds settlement_attempt_count column so the settlement scheduler's retry budget survives a process restart instead of resetting to zero along with the in-memory dead-letter queue.
- claimMarketForSettlement now increments settlement_attempt_count each claim and refuses to reclaim a market once the persisted count hits MAX_RETRY_ATTEMPTS, so the budget holds across restarts. - settleMarketWithRetry now calls the transactional settleMarket path (advisory lock + settlement-attempt row + DB transaction) instead of calling SorobanService directly, so a queued retry is no longer an untracked second code path around the DB.
- Add settlement_attempt_count to existing market fixtures. - New specs: attempt counter increments on every claim, a market that already exhausted its persisted budget is never reclaimed (even without an in-memory queue entry), and a manual retry goes through the same claim/finalize transaction as a fresh sweep.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Idempotent settlement scheduler: persist retry attempt count
The advisory-lock idempotency, DB-transactional claim/finalize, and
exponential backoff for
market-settlement.scheduler.tsalready existed onmain. This PR closes the remaining gap: the retry attempt counter livedonly in an in-memory
Map, so a process restart silently reset a market'sretry budget to zero and a queued retry (
settleMarketWithRetry) bypassedthe DB transaction entirely.
Changes
settlement_attempt_countcolumn toMarket(+ migration).claimMarketForSettlementincrements the persisted counter on every claimand refuses to reclaim a market once it hits
MAX_RETRY_ATTEMPTS, so thebudget holds across restarts.
settleMarketWithRetrynow goes through the same transactionalsettleMarketpath as a fresh sweep instead of callingSorobanServicedirectly.
Testing
pnpm test— 1491/1491 passingpnpm run lint— 0 errorspnpm run build— cleanpnpm run migration:check-timestamps— passedCloses #1763