Repository navigation
fix: wait for traffic control before starting the sync operator [ci] - #82
Merged
Merged
Conversation
In LocalNet, app-synchronizer.sc enables traffic control on the app synchronizer 7 to 9 seconds after it bootstraps the synchronizer. The sync operator, already waiting for the sequencer, checks for traffic control as soon as the sequencer is up and fails init on the first check. Its failure stops the whole splice-node process, so the SV app goes down too and LocalNetDedicatedSyncIntegrationTest gets a 502 or 503 on its first vote request. Retry the check with RetryFor.WaitingOnInitDependency, like the sequencer check before it. A synchronizer that never enables traffic control still fails init, after the retries run out. Signed-off-by: Haiko Schol <haiko@chainsafe.io>
…n [ci] Now that the sync operator waits for traffic control, it starts as soon as app-synchronizer.sc enables it, and its parameter trigger rewrites the synchronizer parameters right away. The script still had the onboarding restriction to set, and both proposed serial 3 within 150 ms. The sync operator's proposal won, the script's was rejected with SerialMismatch, and the script timed out waiting for RestrictedOpen, so LocalNet failed to start. Enable traffic control as the script's last parameter change, so the sync operator only starts once the script is done with the parameters. Signed-off-by: Haiko Schol <haiko@chainsafe.io>
Collaborator
Author
moritzkiefer-da
approved these changes
Oct 14, 2026
Signed-off-by: sadiq1971 <sadiqurr8@gmail.com>
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.
In LocalNet, app-synchronizer.sc enables traffic control on the app
synchronizer 7 to 9 seconds after it bootstraps the synchronizer. The
sync operator, already waiting for the sequencer, checks for traffic
control as soon as the sequencer is up and fails init on the first
check. Its failure stops the whole splice-node process, so the SV app
goes down too and LocalNetDedicatedSyncIntegrationTest gets a 502 or
503 on its first vote request.
Retry the check with RetryFor.WaitingOnInitDependency, like the
sequencer check before it. A synchronizer that never enables traffic
control still fails init, after the retries run out.
With the sync operator waiting, it starts as soon as the script enables
traffic control, and its parameter trigger then updates the synchronizer
parameters while the script is still setting the onboarding restriction.
The two updates collide on the same serial and the script's is rejected,
so LocalNet fails to start. The second commit makes enabling traffic
control the script's last parameter change.