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.
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
fix(api): idempotency bug in registerBroadcastHandler #3558
fix(api): idempotency bug in registerBroadcastHandler #3558
Changes from all commits
528be10
f833574
b215810
3ee3688
df0a32a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
not sure when we began to use non undefinied/null/empty validation (should be
!txn.address
we already had an issue in prod with this) also.. should not include bankowner wallet id validation?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.
In this case I was thinking it should specifically check for the absence of the
address
property (since theOnChainAddress
can technically also be falsy/empty even though it should never be). Or, what sort of issue has this thrown in prod?Maybe not necessary since the reconciliation transaction only ever involves
Liabilities:bankOwner
account andAsset:OnChain
accounts and I believe we only bring inLiabilities
accounts in our ledgerget
methods.address
absence should be enough for this check?Sidenotes:
For this check, ideally it should be a different tx
type
value instead of also being anonchain_payment
so we don't even need the check, but that might be a tricky migration to do. And I also considered maybe setting a custom description for these types of transactions but then there was no way to guarantee that someone couldn't set the same description on normal onchain-payment transactions which would break the heuristic. I switched from checking forsatsFee
presence toaddress
presence since this is more isolated and might less likely eventually be populated on the reconciliation-type transactions that get constructed insideFeeOnlyEntryBuilder
.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.
at least with validations in data from external services we must be more "defensive", we cant guarantee the undefined so it is safer just to use
!txn.address
FYI: the error was a validation using undefined and a service returning null value (typescript in theory was ok but you know we cant trust TS )
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.
Oh yea ok that makes sense.
For here though,
address
is set explicitly in ourtranslateToLedgerTx
function, so there's also less risk of it being something unexpected? We handle the uncertain-falsy-check-from-external-service in the linetx.payee_addresses && tx.payee_addresses.length > 0
insidetranslateToLedgerTx