fix(tap-agent): accept receipts newer than the last redemption - #1086
fix(tap-agent): accept receipts newer than the last redemption#1086Maikol wants to merge 2 commits into
Conversation
Coverage Report for CI Build 32387715723Warning No base build found for commit Coverage: 74.216%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsRequires a base build to compare against. How to fix this → Coverage Stats
💛 - Coveralls |
| })?; | ||
| let receipt_timestamp_ns = receipt.signed_receipt().timestamp_ns(); | ||
|
|
||
| if receipt_timestamp_ns <= last_redeemed_at_ns { |
There was a problem hiding this comment.
Here we're comparing the receipt_timestamp_ns to last_redeemed_at_ns, which comes from the block timestamp of the redeem transaction. When tap-agent collects, it excludes any receipts newer than timestamp_buffer_secs. So I think there's a gap here where some receipts will be lost.
| .await?; | ||
|
|
||
| Ok(!data.payments_escrow_transactions.is_empty()) | ||
| let mut latest_redeemed_at_secs: Option<u64> = None; |
There was a problem hiding this comment.
With no first, orderBy or orderDirection, graph-node will return 100 rows ordered by id.
Adding first: 1 would break sender_account.rs. So this check could use it's own query:
query LatestRedeemTransactionQuery($payer: Bytes!, $receiver: Bytes!, $allocationId: Bytes!) {
paymentsEscrowTransactions(
first: 1
orderBy: timestamp
orderDirection: desc
where: { type: "redeem", payer_: { id: $payer }, receiver_: { id: $receiver }, allocationId: $allocationId }
) { timestamp }
}
2 participants
No description provided.