refactor(stdlib): carry the proposed tip header on chain-proposed events - #25116
Merged
Conversation
nchamo
marked this pull request as ready for review
August 5, 2026 16:04
nventuro
reviewed
Aug 5, 2026
| // below). Throwing here propagates before the tips-store cursor advances, so the cursor stays put and the | ||
| // next sync re-emits chain-proposed (at-least-once). Were we to warn-and-skip, the cursor would advance and | ||
| // a quiet chain would never re-emit, leaving the anchor stale indefinitely. | ||
| throw new Error( |
Contributor
There was a problem hiding this comment.
Are we ok with dropping this error scenario?
Contributor
Author
There was a problem hiding this comment.
I think so. We moved it into a warn in l2_block_stream.ts:
this.log.warn(`No header for the proposed tip; aborting this sync pass`, {
blockNumber: sourceTips.proposed.number,
blockHash: sourceTips.proposed.hash,
});
The idea is that we can retry again and maybe the node error was only temporary. We could potentially remember attempts and fail if we tried too many times, but it feels like an overkill to me
What do you think we should do?
nventuro
approved these changes
Aug 6, 2026
nventuro
enabled auto-merge (squash)
August 6, 2026 19:16
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%) |
Collaborator
|
✅ Successfully backported to backport-to-v5-next-staging #25135. |
This was referenced Aug 6, 2026
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
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.
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-proposedevent 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-proposednow carries the tip'sBlockHeaderas 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_flowstransfers 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.ecdsar1+transfer_0_recursions+sponsored_fpcecdsar1+transfer_1_recursions+sponsored_fpcecdsar1+transfer_0_recursions+private_fpcecdsar1+transfer_1_recursions+private_fpc