After upgrading mainnet to Splice 0.6.7, validator-app fails during initialization while vetting packages. The participant rejects Replace VettedPackages serial Some(30) with TOPOLOGY_TOO_MANY_PENDING_TOPOLOGY_TRANSACTIONS, while the currently observed st
Environment: mainnet
Splice version: 0.6.7
Canton version: 3.5.1
Participant: Solv-Mainnet-01
Validator backend fails during app init / vet packages.
validator-app error:
validator_backend app initialization: Vet packages failed
ABORTED: TOPOLOGY_TOO_MANY_PENDING_TOPOLOGY_TRANSACTIONS
Too many pending topology transactions on this node.
participant log:
Attempting to build, sign, and Replace VettedPackages
serial Some(30)
packages: … 185 more
TopologyManagerWriteService/Authorize failed with:
TOPOLOGY_TOO_MANY_PENDING_TOPOLOGY_TRANSACTIONS
Previous symptom:
check_establish_topology_mapping
FAILED_PRECONDITION
Condition is not yet observed
Proposed: serial = 30, packages = 180
Found: serial = 29, packages = 160
We already scaled validator-app to 0 and waited, then scaled back to 1, but the same error returned.
Need official guidance for repairing/clearing pending topology transactions/outbox for the participant.
After scaling validator-app to 0, participant no longer logs new Replace VettedPackages / TOPOLOGY_TOO_MANY_PENDING_TOPOLOGY_TRANSACTIONS within a 20m window.
Only sequencer reconnect logs remain.
However, scaling validator-app back to 1 reproduces the same vet packages failure.
How to inspect and clear/repair pending topology transactions on a Canton participant
after TOPOLOGY_TOO_MANY_PENDING_TOPOLOGY_TRANSACTIONS during VettedPackages Replace.
Could you also provide the exact steps that reproduce the issue, starting from the last known working state?
In particular:
- The exact upgrade path and deployment steps
- Whether the validator was running below 0.6.5 at the June 27 topology freeze
- Any relevant participant or validator configuration changes
- The complete first
Authorize/ReplaceVettedPackagesfailure, including its error metadata - The synchronizer connection and topology-outbox status
- Whether the issue can be reproduced in a clean environment or LocalNet
If possible, please share a minimal repository, deployment configuration, or sanitized Helm values/docker-compose setup that reproduces the failure. Without the reproduction steps and relevant configuration, it is difficult to determine whether this is a missed-LSU recovery issue, a synchronizer-outbox problem, or validator initialization state.
Since the validator appears to have missed the topology freeze, please confirm whether you have requested and followed the missed-LSU recovery instructions mentioned in the official MainNet announcement.
There is also a generic manual LSU roll-forward procedure, but it requires synchronizer-specific parameters communicated by the SVs and should not be executed speculatively.
I would avoid manually deleting topology state or constructing serial 30 until the correct recovery path has been confirmed. But if possible send a repo, I can review as well