feat(aztec.js): delay first receipt poll after sending a tx - #25089
Merged
Conversation
nchamo
added
ci-draft
nchamo
commented
Aug 3, 2026
| /** The amount of time to ignore TxStatus.DROPPED receipts (in seconds) due to the presumption that it is being propagated by the p2p network. Defaults to 5. */ | ||
| ignoreDroppedReceiptsFor?: number; | ||
| /** The maximum time (in seconds) to wait for the transaction to be mined. Defaults to 60. */ | ||
| /** The maximum time (in seconds) to wait for the transaction to be mined. Defaults to 300 (5 min). */ |
Contributor
Author
There was a problem hiding this comment.
This was outdated, look at the defaults below
nchamo
commented
Aug 3, 2026
| ); | ||
| const tx = await provenTx.toTx(); | ||
| const txHash = tx.getTxHash(); | ||
| if ((await this.aztecNode.getTxReceipt(txHash)).isMined()) { |
Contributor
Author
There was a problem hiding this comment.
This wasn't necessary, as the node already rejects it. I added a test to assert this behaviour
nchamo
marked this pull request as ready for review
August 3, 2026 20:29
Thunkar
approved these changes
Aug 5, 2026
AztecBot
pushed a commit
that referenced
this pull request
Aug 5, 2026
## Motivation Follow-up to #25074 and #25076 in the effort to reduce PXE↔node RPC traffic. Two calls per sent tx were guaranteed wasted: a pre-send `getTxReceipt` used only to reject settled duplicates, which the node's tx validation already rejects via its double-spend check, and the first receipt poll of `.wait()`, issued immediately after `sendTx` when the tx cannot have been mined yet. ## The change - `BaseWallet.sendTx` no longer reads the receipt before sending; duplicate submissions are rejected by the node instead. - `WaitOpts` gains `initialDelay`: seconds to sleep before the first receipt poll. The wallet defaults it to the poll interval, so the first poll now happens where the second poll used to. Environments where receipts are available immediately after sending (e.g. automine) can pass `initialDelay: 0`. - The delay counts against `timeout` (the deadline is fixed before sleeping) and does not consume the DROPPED-receipt grace period, which starts at the first poll. Wallet benchmark results: | | Before → After | |---|---| | `getTxReceipt` calls | 40 → 32 (−20.0%) | | Total node RPC calls | 232 → 224 (−3.4%) | | Node RPC round trips | 163 → 156 (−4.3%) |
Collaborator
|
✅ Successfully backported to backport-to-v5-next-staging #25113. |
This was referenced Aug 5, 2026
nventuro
pushed a commit
that referenced
this pull request
Aug 6, 2026
…nts (#25116) ## Why we are doing this Follow-up to #25089 in the PXE↔node RPC-reduction line. When PXE tracks the proposed chain tip it anchors on the tip's header, but the block stream's `chain-proposed` event only carried the block id, so the PXE handler had to fetch the header back from the node on every tip movement. ## Our fix `chain-proposed` now carries the tip's `BlockHeader` as a required payload, so consumers anchor on the event without a fetch of their own. The stream sources the header from whatever the pass already has: the delivered tip block in block mode, a prefetch that runs in parallel with the reorg walk-back in tips-only mode, or an on-demand by-hash read as a fallback. If the header cannot be obtained the pass aborts and retries on the next poll, so tier events never get ahead of a proposed tip the consumer never received. ## Metrics Measured on the `key_flows` transfers benchmark with a counting wrapper between the benchmarking wallet and the in-process node, applied to both base and this branch. Per-flow calls are unchanged; the saving is one serial fetch (round trip) per tip movement. | Flow | RPC calls | Round trips | |---|---|---| | `ecdsar1+transfer_0_recursions+sponsored_fpc` | 35 → 35 | 26 → 25 (−3.8%) | | `ecdsar1+transfer_1_recursions+sponsored_fpc` | 37 → 37 | 23 → 21 (−8.7%) | | `ecdsar1+transfer_0_recursions+private_fpc` | 56 → 56 | 34 → 33 (−2.9%) | | `ecdsar1+transfer_1_recursions+private_fpc` | 56 → 56 | 32 → 31 (−3.1%) | | whole suite (both wallets, incl. setup) | 460 → 459 | 333 → 320 (−3.9%) |
AztecBot
pushed a commit
that referenced
this pull request
Aug 6, 2026
…nts (#25116) ## Why we are doing this Follow-up to #25089 in the PXE↔node RPC-reduction line. When PXE tracks the proposed chain tip it anchors on the tip's header, but the block stream's `chain-proposed` event only carried the block id, so the PXE handler had to fetch the header back from the node on every tip movement. ## Our fix `chain-proposed` now carries the tip's `BlockHeader` as a required payload, so consumers anchor on the event without a fetch of their own. The stream sources the header from whatever the pass already has: the delivered tip block in block mode, a prefetch that runs in parallel with the reorg walk-back in tips-only mode, or an on-demand by-hash read as a fallback. If the header cannot be obtained the pass aborts and retries on the next poll, so tier events never get ahead of a proposed tip the consumer never received. ## Metrics Measured on the `key_flows` transfers benchmark with a counting wrapper between the benchmarking wallet and the in-process node, applied to both base and this branch. Per-flow calls are unchanged; the saving is one serial fetch (round trip) per tip movement. | Flow | RPC calls | Round trips | |---|---|---| | `ecdsar1+transfer_0_recursions+sponsored_fpc` | 35 → 35 | 26 → 25 (−3.8%) | | `ecdsar1+transfer_1_recursions+sponsored_fpc` | 37 → 37 | 23 → 21 (−8.7%) | | `ecdsar1+transfer_0_recursions+private_fpc` | 56 → 56 | 34 → 33 (−2.9%) | | `ecdsar1+transfer_1_recursions+private_fpc` | 56 → 56 | 32 → 31 (−3.1%) | | whole suite (both wallets, incl. setup) | 460 → 459 | 333 → 320 (−3.9%) |
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
3 participants
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.
Motivation
Follow-up to #25074 and #25076 in the effort to reduce PXE↔node RPC traffic. Two calls per sent tx were guaranteed wasted: a pre-send
getTxReceiptused only to reject settled duplicates, which the node's tx validation already rejects via its double-spend check, and the first receipt poll of.wait(), issued immediately aftersendTxwhen the tx cannot have been mined yet.The change
BaseWallet.sendTxno longer reads the receipt before sending; duplicate submissions are rejected by the node instead.WaitOptsgainsinitialDelay: seconds to sleep before the first receipt poll. The wallet defaults it to the poll interval, so the first poll now happens where the second poll used to. Environments where receipts are available immediately after sending (e.g. automine) can passinitialDelay: 0.timeout(the deadline is fixed before sleeping) and does not consume the DROPPED-receipt grace period, which starts at the first poll.Wallet benchmark results:
getTxReceiptcalls