Skip to content

Resolve shared context entries once per read batch - #3933

Merged
trissim merged 1 commit into
mainfrom
fix/p1086-context-batch
Nov 3, 2026
Merged

trissim merged 1 commit into
mainfrom
fix/p1086-context-batch

Conversation

@trissim

@trissim trissim commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Two files, +112/-31 at the initial checkpoint. This continues P1086 after #3923's authentic original capture succeeded: the saved selection has6,274 entries,54requests and216versions. Its ordinary-reader profile made21,978 ContextEntry.original calls in17.66s;13.07s accumulated in FieldCodec decoding. That is measured reader cost, not attribution of the whole114.85s capture hold.

Mechanism: one batch per ordinary-reader snapshot

Before: each ContextStore.resolve call reconstructed its own predecessor/entry maps. Page reads, selected context annotation reads and original/retained comparison repeated decoding of shared entries for every requested row.

After: the same resolver accepts requested rows and yields their restored contexts. It builds one local dependency map per invocation, reuses shared original entries, and streams restored results. latest, page reads, original_segments and require_retained use that owner. No compatibility overload, persistent cache, extra schema, forwarder, new freezer or changed storage format.

Original and retained connections keep separate maps. Every predecessor edge checks its thread even when already loaded. Dependencies remain segment-only; session AND path AND entry identity remain the keys. Page limits, saved-page object reuse, missing-source/missing-record refusals, complete version comparison and source integrity remain intact.

Removed work

The31deleted lines include per-request restoration loops and repeated source-identity reads. New code factors the shared snapshot lifetime rather than moving it into a service. Four single-row test call sites now consume the batched reader. Added controls cover shared-entry decoding once, foreign-thread predecessors both cold and preloaded, and identical session/entry IDs on different paths.

Evidence

  • Both changed Python files AST-parsed; git diff --check passed.
  • Complete caller search over Core src/tests/tools; sibling Toad src/tests/tools has no direct resolver caller.
  • Baseline profile is retained in shared-board/p1086-selected-reader-profile-01.{json,log,prof}.
  • The bounded leased installed/candidate comparison completed, both exit0, against the same saved selection. All54restored-context fingerprints match; the selected context digest stayed identical before/after both runs. Reader time17.938s ->8.937s; ContextEntry.original calls21,978 ->5,344. This is measured ordinary-reader improvement, not a new114.85s capture measurement.
  • Scoped process maximum RSS increased201,020KiB ->233,428KiB. These figures include that process's reader/fingerprint lifetime; they are neither simultaneous aggregate memory nor complete capture peaks.
  • Exact candidate c5e86d9; context_store.py SHA25647d72bf18d384caabab155ec186324fd9705799686efcfc0e2a5a65d22fc89b9. Saved execution and comparison artifacts: shared-board/p1086-context-batch-{original,candidate,parity}-01.json, matching logs/rc and profiles. Driver .p1086-context-batch-reader-01.py uses installed old code for baseline and checkout src/tools for the candidate; both ordinary readers use the existing TestLease. No advanced original store was opened.
  • New pytest controls are authored, not executed. No local pytest/full suite/NRA gate was run.

Still open

This does not recreate the original capture, certify complete aggregate/temp/WAL/RSS/handle peaks, grant native launch authority or close P867/P667/B4 physical acceptance. The authentic captured cut and all failed/UNKNOWN epochs remain preserved. The entire114.85s hold still lacks internal phase attribution.

Assumed: each batch consumes rows from the same open SQLite snapshot; the iterator is exhausted inside that snapshot by its owning caller. No stored schema or external wire format changes.

Copilot AI balanced review requested due to automatic review settings November 3, 2026 03:38

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

@trissim
trissim added this pull request to the merge queue Nov 3, 2026
Merged via the queue into main with commit 0308f88 Nov 3, 2026
9 of 10 checks passed
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