fix(sync): prioritize bounded public coverage - #2047
Open
branarakic wants to merge 2 commits into
Open
Conversation
branarakic
force-pushed
the
codex/rfc64-m1-public-priority
branch
from
August 3, 2026 08:26
d8b62db to
e748989
Compare
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.
User impact
When a Core node has admitted a bounded batch of public Context Graphs, it now synchronizes both their finalized VM data and live SWM before spending the rest of the peer round on the potentially large
agents/ontologybootstrap backlog.Only scheduler-vetted automatic public CGs receive this priority. Configured or private CGs remain after the Agents/Ontology bootstrap, so private SWM authorization and key recovery always use a refreshed Agents registry. Edge opt-in behavior is unchanged.
Problem
The previous peer round combined system graphs and the bounded public batch into one durable request, then deferred all SWM until that combined request completed. A large or pressured
agentsgraph could therefore time out first and terminate the round even though the user-facing public CGs were ready to converge.The formal M1 gate reproduced this: the Core spent its round transferring tens of thousands of system triples and hit store/RPC pressure before emitting an automatic coverage entry for the three fresh public graphs.
Before
sequenceDiagram participant C as "Core" participant P as "Peer" C->>P: Durable sync agents + ontology + public/configured CGs P-->>C: Large agents backlog P--xC: Timeout or backpressure Note over C: Round stops Note over C: Public VM incomplete and public SWM never attemptedAfter
sequenceDiagram participant C as "Core" participant P as "Peer" C->>P: Durable sync scheduler-vetted public batch P-->>C: Public VM data C->>P: Sync public SWM for the same batch P-->>C: Public SWM data C->>P: Bootstrap agents + ontology + configured scope P-->>C: Refreshed registry and configured VM data C->>P: Sync configured/private SWM Note over C: Public VM and SWM are already evidenced Note over C: Private SWM runs only after registry refreshImplementation
SyncOnConnectScopePlan; the base and lifecycle plans extend it instead of duplicating the contract.preBootstrapPublicContextGraphIds.Validation
sync-on-connect-retry.test.tssync-on-connect-churn.test.tscore-public-coverage-scheduler.test.tsdiscovery-subscription-boundary.test.tssync-coverage-evidence-runtime.test.tssync-coverage-evidence-edge-periodic.test.tspnpm --filter @origintrail-official/dkg-agent run buildgit diff --checkStack
codex/rfc64-m1-core-discovery-wakeup)