Repository navigation
fix: refresh transaction receipts after reorgs - #5406
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 053bfd5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 053bfd5b02
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!replacementResponse) transaction = undefined | ||
| replacementResponse = undefined |
There was a problem hiding this comment.
When a reorg replaces the already-mined replacement with a different transaction in the alternate chain before this refresh runs, retaining transaction prevents the nonce-slot lookup on subsequent polls. The fallback block scan only examines newly emitted block numbers, so it never sees the new replacement's already-past block and waitForTransactionReceipt can time out even though the nonce slot has a confirmed transaction.
Useful? React with 👍 / 👎.
| ) | ||
| return |
There was a problem hiding this comment.
When a reorg re-mines the same transaction in an earlier block, this early return computes confirmations from the discarded receipt and delays reading the canonical one. For example, if the cached receipt was in block 100, the canonical receipt moves to block 99, and three confirmations are requested, at head 101 the canonical receipt is ready but this check sees only two confirmations and waits another block; a timeout during that interval incorrectly rejects an already-confirmed transaction.
Useful? React with 👍 / 👎.
| // A reorg can remove a receipt or change its execution outcome, | ||
| // so it is refreshed once it has enough confirmations. Other | ||
| // errors keep the cached receipt for the next block. | ||
| const receipt_ = await getAction( | ||
| client, |
There was a problem hiding this comment.
This refresh only runs when receipt was already cached before the block callback. If the initial lookup returns no receipt and a later block poll first receives one that already satisfies confirmations, the lower fetch path resolves it immediately without this validation; a reorg while that response is in flight can therefore still return the discarded receipt that this change is intended to prevent.
Useful? React with 👍 / 👎.
Refreshes
waitForTransactionReceiptreceipts once confirmations are met, keeps waiting on transient refresh errors, and keeps the replaced transaction when a reorg removes its replacement. Supersedes #5386.