fix: init bb.js sync singleton before subsystems start in createAndSync#24147
Merged
PhilWindle merged 2 commits intoJun 17, 2026
Merged
Conversation
The prover node begins monitoring epochs as soon as it is created in createAndSync, and epoch proving deserializes compressed Chonk proofs via ChonkProof.fromBuffer -> BarretenbergSync.getSingleton(), which throws "First call BarretenbergSync.initSingleton()" if the singleton has not yet been initialised. The existing init in aztec_start_action runs later and is guarded on services.aztec, leaving a race that crashed EpochSession jobs in production. Initialise the singleton at the top of createAndSync so every subsystem (and every createAndSync caller) is covered.
createAndSync now imports @aztec/bb.js to initialise the sync singleton, so declare it as a dependency. Fixes the import-x/no-extraneous-dependencies lint error.
ludamad
approved these changes
Jun 17, 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
2 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.
Problem
A prover node in production crashed an epoch proving job:
The error comes from
BarretenbergSync.getSingleton()throwing when the WASM singleton has not been initialised. Epoch proving deserializes compressed Chonk proofs viaChonkProof.fromBuffer→ChonkProof.fromCompressedBytes→getSingleton().The prover node starts monitoring epochs as soon as it is created inside
AztecNodeService.createAndSync. The only init on the start path (aztec_start_action.ts) runs later and is guarded onservices.aztec, so anEpochSessioncan reach the decompress path before the singleton is initialised — the race that crashed the job in production.Fix
Initialise the singleton at the top of
createAndSync, before any subsystem runs. This covers the prover node, validator, sequencer, and every othercreateAndSynccaller (including e2e tests).The existing
initSingleton()call inaztec_start_actionis left in place —initSingletonis idempotent (the singleton promise is cached), so it remains a harmless guard for the RPC schema-parsing path.Fixes A-1243.