Repository navigation
fix(onlion): fold at one batch so the read window covers everything waiting - #121
Merged
Merged
Conversation
…aiting Reading the newest entries fixed the streaming case and left the mirror image: the window holds eight entries, the standing backlog lived between the batch and the trigger (16..23 at a trigger of 24), so whichever end the window took, part of it was invisible until it folded. The backlog is what has to change, not the end. Folding as soon as one batch is waiting keeps pending below the window, and it costs no extra partition writes: a fold absorbs exactly one batch, so the cadence is one fold per batch of accepts at any trigger above the batch. What the lower trigger removes is the standing tail, not throughput. `MAX_PENDING_READ` grows to two batches because the trigger is not a hard bound - with concurrent accepts a few more can arrive before the fold commits, and anything past the window is invisible. The cost is one embedding call per entry actually pending, normally one batch and never this bound. Pinned by a test that adds twenty facts one at a time and requires all twenty to be searchable with the log still live, plus the pending count below the window. Verified: npm run verify passes (34 PASS).
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 this fixes
The previous version read the newest pending entries, which fixed the streaming case and left
the mirror image: the window holds eight entries while the standing backlog lived between the
batch and the trigger (16..23 at a trigger of 24), so whichever end the window took, part of it
was invisible until it folded.
Measured on the deployed service, twenty sequential Adds to one user:
The change
FOLD_TRIGGERdrops toFOLD_BATCH: folding as soon as a full batch waits keeps pendingbelow the read window. It costs no extra partition writes - a fold absorbs exactly one batch,
so the cadence is one fold per batch of accepts at any trigger above the batch. What it
removes is the standing tail.
MAX_PENDING_READgrows to two batches, because the trigger is not a hard bound: withconcurrent accepts a few more can arrive before the fold commits, and anything past the
window is invisible. The cost is one embedding call per entry actually pending.
log is still live, with the pending count below the window.
Verification
npm run verify: 34 PASS.dprdf1xm08hi, live revisionadfa1f9c,pending_read_limit: 16,merge_batch: 8.pending_entries: 4,sqlite_bytes1.63 MB (the folds ran), and all twenty markers were found.