fix: filter third-party bank_tx and fix receiver trimming in pending balance#3484
Open
TaprootFreak wants to merge 2 commits intodevelopfrom
Open
fix: filter third-party bank_tx and fix receiver trimming in pending balance#3484TaprootFreak wants to merge 2 commits intodevelopfrom
TaprootFreak wants to merge 2 commits intodevelopfrom
Conversation
TaprootFreak
force-pushed
the
fix/scrypt-eur-pending-balance-v2
branch
from
e8e02db to
e35b420
Compare
…ding balance Three issues caused Scrypt EUR pending balances to be invisible: 1. Third-party EUR deposits (txId=null) inflated the receiver sum 2. Third-party bank_tx (instructedCurrency=null) inflated the sender count 3. filterSenderPendingList did not trim orphaned receivers when sender and receiver counts were equal — old receivers whose senders aged out of the 21-day window absorbed new unmatched senders, netting to 0 Fix: filter foreign transactions from both lists, and when counts are equal, detect senders newer than all receivers (definitely unmatched) and trim corresponding orphaned old receivers.
TaprootFreak
force-pushed
the
fix/scrypt-eur-pending-balance-v2
branch
from
e35b420 to
978a6dd
Compare
…tching The previous approach used filterSenderPendingList + sum difference to calculate pending Scrypt balances. This was fundamentally flawed: old receivers whose senders aged out of the 21-day window created false negatives, making pending transfers invisible. New approach: getUnmatchedSenders() matches each sender with a receiver 1:1 by amount and chronological order (same criteria as findSenderReceiverPair). Only truly unmatched senders contribute to the pending balance — no receiver subtraction needed. Applied to all 4 Scrypt directions (CHF/EUR × Bank→Scrypt/Scrypt→Bank), both filtered and unfiltered paths. Kraken paths unchanged.
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
Replaces the flawed sum-based Scrypt pending balance with correct 1:1 transaction matching.
Problem:
filterSenderPendingListreturned windowed sender/receiver lists, andgetPendingBankAmountsummed them independently. When old receivers' senders aged out of the 21-day window, orphaned receivers created false negatives — making pending transfers (e.g. 30k EUR) invisible in the FinancialDataLog.Solution: New
getUnmatchedSenders()method matches each sender with a receiver 1:1 by amount and chronological order (same criteria asfindSenderReceiverPair). Only truly unmatched senders contribute to the pending balance — no receiver subtraction needed.Changes
getUnmatchedSenders(senders, receivers)with 1:1 greedy matchingtxIdfor exchange_tx,instructedCurrencyfor bank_tx)Net effect: -94 lines, +72 lines (simpler code)
Test plan
filterSenderPendingListtests pass (9/9)toScrypt/fromScryptpending amountstoScrypt !== toScryptUnfilteredcomparison doesn't trigger false errors