Repository navigation
D-GSO-8: seal boundary (P8) - #1363
Conversation
Internal events change only working rows and never write durably. A declared Boundary event seals the rows changed since the last seal with the shipped persist_sink::DetachedCycleBatch::freeze into a local ledger (cycle, base version, frozen batch); a boundary with nothing changed writes nothing. Replaying the persisted events from each prior seal reproduces the next seal exactly: frame, landings, coalesced image and batch_hash. A wrong base, a dropped event and a swapped order on one row each change the seal. Tie limit (plan §18 P8, option 1): the stream key is the event's own durable, globally unique sequence number, and a batch with a tied key is refused instead of sealed. A test shows on the real freeze that tied keys make the coalesced image and the hash depend on arrival order. Not exercised: WalSink publication, fencing and recovery (the ledger is local); which semantic events earn a boundary; the internal operation is a stand-in fold. 6 tests, 5 disable runs red. Board: D-GSO-8 In PR; D-GSO-7 Shipped (#1360); the D-GSO-6 follow-up marked Shipped (#1362). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DgxrCafsJuAahpBs7oC14R
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing (3)
✨ Finishing Touches📝 Generate docstrings
Warning Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: 0a6e1f69-c273-4644-8b3b-2b0d5b1356a2) |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c615d182ad
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if let Some(k) = first_tie(&casts) { | ||
| return Err(SealError::TiedKey(k)); |
There was a problem hiding this comment.
When two Internal events reuse a seq on the same row, or reuse one across separate seals, casts() has already reduced them to one slot in the current batch, so first_tie returns None and the seal is accepted. This violates the probe's globally unique durable-key precondition: replay cannot recover the live arrival order for those events from the duplicated key and may produce a different next seal. Track and reject duplicate event sequence numbers across the engine lifetime before folding or row coalescing.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed: uniqueness was stated but never checked, and both reuse cases got past first_tie. #1363 merged before the fix landed, so it is in a follow-up PR on claude/gso-8-seq. apply now refuses a seq that is not greater than the last one accepted, and resume_after restores the highest persisted key. The new test a_reused_seq_is_refused covers a reuse on the same row, a reuse across seals and a reuse after a resume, and was verified with disable runs.
Generated by Claude Code
2 participants
What
P8 of
.claude/plans/2026-10-06-global-sudoku-replayable-orchestration-v1.md: run many internal operations without durable materialization, seal only at one declared semantic boundary, and show that replay from the prior seal reproduces the next seal (§15, §18 P8).crates/lance-graph-planner/examples/seal_boundary_probe.rs(planner tests already run in CI), no library code changes.Boundaryevent seals the rows changed since the last seal with the shippedpersist_sink::DetachedCycleBatch::freeze. The seal goes into a local ledger as cycle, base version and frozen batch.batch_hash.Demo run: 1000 internal operations produce 4 seals of 5 landings each, and the last seal replays exactly.
The tie limit
The plan names this limit:
freezesorts stably, so equalstream_positions keep their arrival order, and arrival order is not durable. Of the three options in the plan, this probe takes option 1: the stream key is the event's own durable, globally unique sequence number, and a batch with a tied key is refused rather than sealed. A test shows on the realfreezethat tied keys make both the coalesced image and the hash depend on arrival order, which is why the refusal is needed.Scope limits
WalSinkis driven, so publication, fencing and recovery are not exercised.Tests (6) and disable runs (5, all red)
freeze, and the probe refuses them — D3: tie check removed; D5: key not the durableseqBoard
STATUS_BOARD: D-GSO-8 In PR; D-GSO-7 Shipped (#1360); the D-GSO-6 follow-up marked Shipped (#1362). The branch is rebased on main including #1361 and #1362.
🤖 Generated with Claude Code
https://claude.ai/code/session_01DgxrCafsJuAahpBs7oC14R
Generated by Claude Code
Summary by CodeRabbit