Skip to content

feat(egress)!: support recovery-aware snapshot-to-tip replication - #38

Closed
GCdePaula wants to merge 3 commits into
feature/application-c-bridgefrom
feature/track3-history-read-foundation
Closed

GCdePaula wants to merge 3 commits into
feature/application-c-bridgefrom
feature/track3-history-read-foundation

Conversation

@GCdePaula

@GCdePaula GCdePaula commented Sep 16, 2026 •

Copy link
Copy Markdown
Member

Subscribers can now restore an application snapshot, replay its backlog, follow the optimistic tip, and rebootstrap after recovery invalidates their history.

Changes

  • Separate executed application inputs from raw L1 observations. Every replay entry has a canonical offset; batch envelopes remain outside the application feed.
  • Replace invalidated history suffixes and advance recovery generation atomically. Publish complete era baselines and select immutable checkpoints from L1 acceptance facts.
  • Serve complete restore archives through /latest_snapshot and accepted recovery archives through /finalized_snapshot, with history identity and count tied to the artifact lease. Preserve the watchdog comparison routes.
  • Require era_id, recovery_generation, and next_input on WebSocket subscriptions. Replay inclusively into live delivery; refuse incompatible history and positions ahead of the head. Update the Rust SDK and consumer documentation.

Validation

Local validation at 7f3229f: 712 host tests, 62 watchdog tests, workspace checks, strict Clippy, formatting, and external C archive/downstream-consumer smoke checks passed. Five end-to-end scenarios passed against a freshly built emulator 0.20 image, covering cold replication, ordinary execution, stale recovery, and reconstruction from an exported checkpoint.

The complete bootstrap/recovery journey through the C host, private DEX qualification, and representative deployment latency remain follow-up integration work.

Validate history claims before inclusive canonical pagination and capture snapshot history identity with the artifact lease. Preserve existing HTTP and WebSocket behavior for the coordinated consumer cutover.

Cover recovery replacement, coherent reads, rebuilt history bases, deep backlogs, and lease metadata. Record the accepted snapshot-to-tip workflow and remaining API work.
Use one current application sequence with mandatory offsets and atomic recovery suffix replacement. Publish complete era baselines and derive immutable batch snapshot acceptance directly from L1 facts.

Serve restorable HTTP archives and require versioned canonical WS claims. Update SDK, recovery exports, watchdog metadata, tests, and architecture documentation.
Exercise nonempty HTTP restore, concurrent catch-up, live replication, and recovery rebootstrap through the consumer API. Preserve Lua module paths in doctor and correct benchmark fee defaults uncovered during validation.

Record pinned emulator 0.20 canonical-machine gates and an exact-revision ABBA latency comparison. Native engine conformance and deployment latency remain separate integration gates.
@GCdePaula
GCdePaula force-pushed the feature/track3-history-read-foundation branch from 4fc010c to 7f3229f Compare September 17, 2026 13:05
@GCdePaula
GCdePaula changed the base branch from main to feature/application-c-bridge September 17, 2026 13:05
@GCdePaula

Copy link
Copy Markdown
Member Author

Rebased on feature/application-c-bridge, to be merged after #36.

@GCdePaula GCdePaula changed the title feat: add versioned canonical history read foundation feat(egress)!: support recovery-aware snapshot-to-tip replication Sep 17, 2026
@GCdePaula
GCdePaula added this pull request to stack #40 September 17, 2026 14:00
stephenctw
stephenctw previously approved these changes Sep 19, 2026
@GCdePaula

Copy link
Copy Markdown
Member Author

Superseded by #45.

@GCdePaula GCdePaula closed this Sep 22, 2026
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