Skip to content

fix(bot): check L1-to-L2 message readiness against PXE sync tip#24004

Open
spalladino wants to merge 4 commits into
merge-train/spartan-v5from
spl/a-1155-fix-wait-for-l1-to-l2-msg
Open

fix(bot): check L1-to-L2 message readiness against PXE sync tip#24004
spalladino wants to merge 4 commits into
merge-train/spartan-v5from
spl/a-1155-fix-wait-for-l1-to-l2-msg

Conversation

@spalladino

@spalladino spalladino commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

Motivation

The bot waits for its Fee Juice bridge claim with waitForL1ToL2MessageReady and then immediately simulates the account deployment that consumes the claim. Readiness was always evaluated against the latest block, but the bot's embedded PXE can be configured to sync to a slower tip (e.g. syncChainTip=checkpointed). When the tips diverge, readiness passes while the PXE simulation anchors to an older block whose message tree does not contain the message yet, and simulation fails with No L1 to L2 message found for message hash ..., sending the bot into a crash loop where it repeatedly validates a claim it cannot consume.

Approach

Make readiness answer the question the consumer actually needs: is the message present at the same chain tip the consuming PXE will anchor its simulation to?

  • isL1ToL2MessageReady / waitForL1ToL2MessageReady accept an optional chain tip (BlockTag), defaulting to latest so existing callers are unaffected. The helper compares the message checkpoint against the block at the requested tip.
  • The bot does not get a new config knob and no wallet APIs change: addBot extracts syncChainTip from the same PXE options its callers use to build the embedded wallet, and threads it through BotRunner → bot createBotFactory. This keeps the readiness tip from drifting from the PXE's actual config. Polling the node at the PXE's configured tip (rather than exposing the PXE anchor) is required for the wait to make progress, since the PXE synchronizer is pull-on-demand and its anchor only advances on pxe.sync().
  • All bot readiness checks now pass the tip: the stored-claim revalidation and the new-claim wait in BotFactory, the cross-chain setup wait, and the steady-state message selection in CrossChainBot.

API changes

isL1ToL2MessageReady(node, msgHash, chainTip?) and waitForL1ToL2MessageReady(node, msgHash, { timeoutSeconds, chainTip? }) in @aztec/aztec.js/messaging accept an optional BlockTag (default 'latest', preserving previous behavior). Their node dependency narrowed from getBlock to the cheaper getBlockData.

Changes

  • aztec.js: tip-aware readiness helpers in utils/cross_chain.ts; new unit tests covering the latest fallback and the tip-aware path.
  • bot: BotRunner, Bot/AmmBot/CrossChainBot.create, and BotFactory accept the PXE sync tip and use it at every L1-to-L2 readiness check.
  • aztec: addBot extracts syncChainTip from the PXE options and passes it to BotRunner.

Fixes A-1155

The bot waits for L1-to-L2 message readiness against the latest tip while
its embedded PXE may sync to an older tip (e.g. proven/checkpointed). This
let readiness pass on a newer proposed/latest block while PXE simulation
anchored to a tip where the message was not yet in the message tree,
crashing the bot when it then tried to consume the message.

Extend isL1ToL2MessageReady/waitForL1ToL2MessageReady to accept an optional
chain tip (default latest, preserving existing behavior) and thread the
PXE syncChainTip from bot setup through BotRunner and BotFactory into all
readiness checks, including CrossChainBot message selection.
@AztecBot

AztecBot commented Jun 10, 2026

Copy link
Copy Markdown
Collaborator

Flakey Tests

🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry.

\033FLAKED\033 (8;;http://ci.aztec-labs.com/e626f4270969f8bc�e626f4270969f8bc8;;�):  yarn-project/end-to-end/scripts/run_test.sh simple src/e2e_epochs/epochs_optimistic_proving.parallel.test.ts "removes a checkpoint mid-epoch via reorg and proves with survivors" (226s) (code: 0) group:e2e-p2p-epoch-flakes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants