rfc: reuse accepted merge context and bound table preparation - #638
Merged
Conversation
aaltshuler
marked this pull request as ready for review
September 6, 2026 14:52
This was referenced Sep 6, 2026
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.
What & why
Accept RFC 0057 for reusing the accepted merge context and preparing eligible tables in bounded ordered windows. Preserve the existing three-way semantics, authority checks, combined validation, recovery ownership, serial durable effects, and single graph publication.
This is the canonical design record. It consolidates the amended proposal from #668 and resolves the RFC-number collisions with current main. RFC 0056 is reserved by #670; retained merged ancestry in #662 is a separate draft reallocated to 0058.
This PR changes documentation and evidence only. Context reuse is implemented in pending #662; pending #668 supplies the diagnostic scheduler. Neither runtime PR is merged by accepting this design. Production remains width one, and HTTP retains its independent width-one ceiling.
Current evidence and disposition
The checked-in portable receipt contains all 29 matched pairs / 58 timed merges, source and executable hashes, fixture parameters, resource settings, and phase/count/resource summaries. Five alternating pairs per main point used 121 populated tables with four rows each and 17 ms delay per observed ObjectStore API call.
The baseline already includes context reuse; these results isolate the scheduler. The one-table regression is within 10%, but both multi-table points fail the 2× activation gate. The threshold remains unchanged.
Small history controls (four tables, 16 live rows, two pairs each) fall from 1.72× at H0 to 1.44× at H16 and 1.23× at H64. Manifest preparation/publication still dominate older graphs. Largest persisted fixture: 9.605 MiB; maximum observed benchmark-process RSS: 71.5 MiB. This does not qualify decoder memory or every legacy physical format.
These are local release diagnostics, not S3 latency or p95 claims. The cloud AWS performance benchmark has not run. AWS-feature correctness CI is separate. Preserve the original 24-run prototype CSV and exact patch archive as explicitly historical evidence; its 2.35×/2.51× numbers are not current implementation results.
Backing issue / RFC
Related work: #641 (history/catalog costs), #642 (fork/delete amplification), #643 (independent-target serialization). This PR does not close those issues.
Validation
Remaining activation gates
Native pre-decode allocations and serial-valid acceptance; useful overlapping Blob/failure/fallback/cancellation/recovery coverage; the 2× speed gate and deployed-store benchmark evidence. HTTP also requires request-independent operation ownership and shutdown drain.
status: accepted,implementation: in-progressrecords design acceptance while retaining these explicit gates.