fix: re-sync exchange transactions after later status changes#3752
Draft
TaprootFreak wants to merge 4 commits into
Draft
fix: re-sync exchange transactions after later status changes#3752TaprootFreak wants to merge 4 commits into
TaprootFreak wants to merge 4 commits into
Conversation
Exchange transaction status updates were not persisted on a later sync once a row left the 'pending' state. The sync window (getSyncSinceDate) only widened for still-pending transactions, so a deposit that was flipped to 'failed' by the local stale-pending cleanup never re-entered the fetch window and a subsequent confirmation on the exchange was lost. Widen the sync window to also cover recently-failed transactions within a bounded re-check horizon, so a status change on the exchange reliably reaches the database.
Add a regression spec for getSyncSinceDate, the .env.example entry for EXCHANGE_TX_SYNC_RECHECK_DAYS, and a comment clarifying that the recheck horizon is keyed on externalCreated to align with getAllTransactions.
Rework the getSyncSinceDate spec so it genuinely covers the fix instead of re-implementing the WHERE clause in the mock. The query test now captures the findOne argument and asserts the status and externalCreated predicates, and the date-logic tests mock a fixed result without re-deriving the filter. Adopt the standard Test.createTestingModule setup used across the repo.
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
1 participant
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.
Summary
Exchange transaction (
exchange_tx) rows could get permanently stuck onstatus='failed'even after the exchange later confirmed the transaction (Completed). The later status change was never persisted, leaving downstream balance reporting with phantom pending entries.Root cause: the hourly
cleanupStalePendingDepositsjob flips long-pending deposits tofailed.getSyncSinceDatethen computed the re-sync window only frompendingrows — once a transaction was flipped tofailedit no longer kept the window open, fell outside the fetch window, and a laterCompletedevent from the exchange was never re-fetched or persisted.Changes
getSyncSinceDatenow widens the re-sync window from transactions instatus In ('pending', 'failed'), bounded by a newexchangeTxSyncRecheckDayshorizon (default 7 days, env-overridable) so the window cannot grow unbounded.EXCHANGE_TX_SYNC_RECHECK_DAYSto config and.env.example.exchange-tx.service.spec.tscoveringgetSyncSinceDate(query construction + window arithmetic).Test plan
lint, format check,type-check,buildpassexchange-tx.service.spec.tspasses (4 tests)ok