fix(logread): walk past an oversized line instead of stopping at it

[Behnam-RK]

Closes #64.

A bufio.Scanner cannot resume past ErrTooLong, so one line over the 4 MiB cap ended the scan: the records before it survived, and that line and every record after it in the same file did not. 0.15.0 shipped that as a documented limit (CHANGELOG.md:191-198).

A bufio.Reader hands a long line back in pieces (ReadLine's isPrefix), which is what makes it possible to walk past one without ever holding it. The loop drains the pieces, counts the bytes, and keeps going.

The skipped line leaves a record, not a gap

time=2026-09-13T10:00:00Z level=ERROR msg=before
level=WARN msg="log line too long to read; skipped" logread.oversized=5000000 limit=4194304
time=2026-09-13T10:00:02Z level=ERROR msg=after

That middle line is new; the third line is what is lost today.

• Raw is a real slog line, because dezhban logs in text mode (logs.go:93-95) and the bundle's log.txt (report.go:341-343) print Raw and nothing else — a marker with an empty Raw prints a blank line exactly where the explanation belongs. ParseLine(Raw) round-trips it, so log.txt stays readable by the code that wrote it.
• Time is zero, because the timestamp was inside the bytes that went. That also means a --since query cannot hide a gap whose position it has no way to know. Swift's isGoZero already renders it as no date.
• WARN, not ERROR. dezhban did not fail, and the skipped line might have been anything — claiming ERROR would rank a guess against real records. The cost is stated in cli.md: --level error hides the stand-in, so ask for warn when you want to see gaps.

A pinned behaviour is deliberately reversed

Such a file is no longer reported as a partial read. It was read to its end; one line was not a record.

TestALineOverTheCapKeepsTheRecordsBeforeIt asserted the opposite —

if err == nil { t.Error("a line past the cap must still be reported") }

— so its name and its assertion are both reversed here. That is a choice, not a break, and it is called out rather than buried under a green suite. The error path stays for what it was built for, and TestAnUnreadableArchiveDoesNotCostTheLiveFile is now the only test holding it open, which its comment now says.

Also in this change

• The 4 MiB literal becomes maxLineBytes. It was restated in this package's prose, in two tests and in a doc; a limit living in four places is one that drifts. The cap also becomes inclusive — Scanner errored when its buffer was full at max, so the old true maximum was one byte below the number everything else stated (pinned by TestALineExactlyAtTheCapIsStillARecord).
• internal/redact keeps logread's attr keys out of the hostname pass. They are namespaced with a dot, which gives them a hostname's shape, and logread.oversized reaches a bundle inside Raw — without an exact-match keep, log.txt read host-1=5242880 and the legend counted a hostname standing for an attr key. logread.unparsed is listed alongside for the identical reason, not because it leaks today: it lives only in Attrs, and reportLog writes Raw.

Tests

Nine of the ten new tests fail against the code they guard. The tenth, TestALastLineWithNoTrailingNewlineIsStillRead, passes both ways and is kept anyway: the Scanner handled that case for free, and a hand-rolled loop that emits after the io.EOF check rather than before it is exactly how it gets lost.

Coverage: resumption; the marker's shape and Raw round-trip; a long line as the unterminated last line; two long lines each carrying their own count; a long line in a rotated archive costing neither its own tail nor the live file; the inclusive cap; the level filter in both directions; the --since behaviour; and memory.

Memory — measured, and the plan's number was wrong

I predicted ~8 MiB. It is ~20 MiB cumulative, five times the cap, because append's growth factor for large slices is about 1.25 and the intermediate copies add up.

What matters is that it is flat:

line	allocated
4 MiB	20,264,336
8 MiB	20,248,248
16 MiB	20,253,664
64 MiB	20,248,248

So TestDrainingALongLineCostsTheCapNotTheLine compares two reads whose lines differ by 16× and asserts the allocation barely moves — which a buffering design cannot satisfy at any threshold — instead of pinning a constant nobody can defend.

Review loop

Round	Reviewer	Findings	Pre-existing	Loop-introduced	Defects fixed
0	me, before asking	1	0	1	1
1	read-only subagent	1	0	1	1

Neither round found a correctness defect in the reader. Both found something worth having, and both were about this branch's own output — named rather than absorbed:

• Round 0 (mine): nothing pinned the half of this change that is pure risk — that ordinary files still read identically. The per-case tests each check one behaviour. Added logread_diff_test.go, a differential over 300 random files against a verbatim copy of the old Scanner loop, built from the shapes that have caused trouble in this package before.
• Round 1 (reviewer): maxLineBytes' doc comment claims the cap is stated in docs/usage/cli.md and that changing it means changing the doc. The claim was false — the paragraph never landed. An edit script's assert fired on an earlier hunk, I took it for the later one, and nothing caught it afterwards because prose is not compiled. Fixed the paragraph and added TestTheDocumentedLineCapMatchesTheCode, which fails by name without it. This was the second doc edit in the session to disappear the same way, which is the argument for a test over a retype.

The reviewer worked the loop by hand for a lone over-cap line, an over-cap first line, back-to-back long lines, a length landing on a buffer boundary, a \r straddling a read, and an archive tail — plus the int64/int conversion, capacity retention, the marker across all four consumers, and which tests bite. No BUG or RISK.

Verification

task check, GOOS=linux/windows go vet, swift test (270). Plus a real 5 MB-line fixture through all four surfaces: the record after the long line comes back, stderr is silent, --level error hides the marker, --json carries the zero time Swift decodes as nil, and log.txt keeps logread.oversized=5000000 with an empty legend.

One honest limit on that last check: dezhban logs resolves its state directory from a fixed path with no env override, so the fixture was driven through logread.Read and redact.Text directly rather than through the installed binary. The CLI's own contribution to those paths is fmt.Println(r.Raw) and the stderr warning, both of which the assertions above cover. The on-host checklist item added to docs/contribute/testing.md is the version a human runs against the real thing.

🤖 Generated with Claude Code