Surface truncation instead of silently compacting a partial log window#9
Open
NGHINAI wants to merge 1 commit into
Open
Surface truncation instead of silently compacting a partial log window#9NGHINAI wants to merge 1 commit into
NGHINAI wants to merge 1 commit into
Conversation
All input paths cap collection at 20k lines and kill the child when the cap is hit, keeping the oldest lines and dropping the newest — but nothing in the output said so. An agent (or user) debugging an incident saw a confident compaction summary computed over a slice that often excludes the incident itself, since recent lines are the ones that matter and file reads put them at the end. Closes the visibility half of codag-megalith#7: - exec.Collect now reports whether the line cap cut the stream short (Streamed.HitLimit), and readLines/readNonEmptyLines detect a dropped non-empty line past their caps. - CLI wrap prints a stderr warning (even with --quiet — coverage is correctness, not chrome) for both the line cap and the 90s collection timeout, before the compaction starts. - MCP tools append a "[codag] note: ..." to the returned text for both cases, telling the agent to narrow the window (--since/--tail) and rerun. The keep-newest ring-buffer alternative from codag-megalith#7 is left as a follow-up since it changes the latency profile; this makes the current behavior honest first. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Implements the minimal fix from #7. All input paths cap collection at 20k lines and kill the child at the cap, keeping the oldest lines and dropping the newest — and nothing in the output said so. For incident debugging that's the wrong slice to keep silently: the incident is usually in the recent lines, and a confident "N→M tok" summary over a partial window reads as full coverage.
This PR makes the behavior honest everywhere it bites:
exec.Collectnow reports cap-hits (Streamed.HitLimit());readLines/readNonEmptyLinesdetect a dropped non-empty line past their caps (trailing blanks don't count).--quiet— coverage is correctness, not chrome — and stays off stdout so pipes/agents get clean output. Happy to gate it on--quietinstead if you prefer.[codag] note: input truncated at 20000 lines — the oldest 20000 were compacted and the newest dropped. Narrow the log window (e.g. --since, --tail, --limit) and rerun for full coverage.(and an equivalent note for the 90s timeout), so an agent can react instead of trusting a partial compact.Demo:
codag wrap -- sh -c 'seq 1 25000'→The keep-newest ring-buffer alternative from #7 is deliberately left out — it changes the latency profile (child runs to completion instead of dying at the cap), so it deserves its own discussion. This makes current behavior visible first.