fix: reset the auto-capture watermark after valid-empty extractions#948
Draft
gorkem2020 wants to merge 2 commits into
Draft
fix: reset the auto-capture watermark after valid-empty extractions#948gorkem2020 wants to merge 2 commits into
gorkem2020 wants to merge 2 commits into
Conversation
gorkem2020
force-pushed
the
fix/autocapture-reset-on-valid-empty-extraction
branch
from
July 15, 2026 19:33
d219e6c to
33cacff
Compare
gorkem2020
force-pushed
the
fix/autocapture-reset-on-valid-empty-extraction
branch
from
July 17, 2026 21:36
33cacff to
19a9143
Compare
…action A "valid-empty" extraction result (the LLM genuinely ran and confirmed the batch had nothing worth storing, not a failure) skipped the issue CortexReach#417 Fix CortexReach#5 watermark reset that a successful (created/merged > 0) extraction already applies. The counter was left at whatever the pre-extraction cumulative set it to, so the very next turn re-fired on just one new message instead of waiting for a fresh minMessages-sized window. Live-fleet trace (transport=host, extractMinMessages=2, ingress-fed webchat session): a valid-empty extraction at a fresh cursor, followed by turns that either mis-fired early or produced inconsistent windowing depending on exact message timing -- traced to this exact gap. Confirmed via `git show master:index.ts` that this predates every fleet-2026-07-13 feature branch; not a composition artifact, so it lands on its own branch rather than touching any live PR head. Fix: apply the same counter reset (issue CortexReach#417 Fix CortexReach#5) on the valid-empty path as on the successful path, since both represent a batch the extractor genuinely and conclusively considered. Red-first: test/autocapture-reset-on-valid-empty-extraction.test.mjs reproduces the exact ingress-fed sequence (3-text valid-empty turn, then a single new message, then a second new message) using the real plugin harness (message_received + agent_end). Watched it fail (turn 2 re-fired with extractionPrompts.length going to 2 instead of staying at 1) against the pre-fix code, then confirmed green after the fix. No regression in test/smart-extractor-branches.mjs or test/functional-e2e.mjs. Registered in package.json's test chain and scripts/ci-test-manifest.mjs.
gorkem2020
force-pushed
the
fix/autocapture-reset-on-valid-empty-extraction
branch
from
July 18, 2026 15:52
19a9143 to
c747bb5
Compare
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
1 participant
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.
The agent-end auto-capture watermark (
autoCaptureSeenTextCount) is reset after a successful extraction, but a valid-empty extraction (the LLM legitimately returns zero candidates) returns early and skips that reset. The counter then carries a stale, too-high value into the next turn.In ingress-fed sessions (
message_receivedfeeds the pending-texts queue and each agent end delivers only the newest messages) this makes the very next turn fire extraction prematurely on a single genuinely new message, instead of waiting for a freshextractMinMessages-sized window. In history-carrying sessions the asymmetry happens to be a no-op (the cumulative count is recomputed from the full history each turn), which is why it went unnoticed.What changed
The valid-empty path now applies the identical watermark reset as the successful path. Both cases represent a batch the extractor genuinely and conclusively considered; only errored extractions leave the counter untouched.
Test plan
New regression test reproduces the exact ingress-fed sequence with the real plugin harness: a three-text turn whose extraction returns valid-empty, then one new message (must defer), then a second new message (fires normally). Watched red against the pre-fix code (the one-message turn fired prematurely), green after. The existing watermark and fallback-gating suites pass unchanged.
Found while live-testing the runtime transport work; the defect predates all current feature branches and reproduces on plain master, so it ships on its own branch.