64 lines
3.2 KiB
Markdown
64 lines
3.2 KiB
Markdown
# 054 — `log stream` output isn't recognized as a known format (folds into ticket 050)
|
|
|
|
## Summary
|
|
|
|
The report was "`log stream |& ottyl` should capture the format
|
|
properly... tab separated format is being ignored, add it as a known
|
|
type." Investigating `huig_dump.txt` (a real `log stream` capture already
|
|
in the repo root) shows the premise needs correcting: the file is **not**
|
|
tab-separated. `grep -P "\t"` finds a literal tab character on only 3 of
|
|
697 lines, and none of those are the header or a representative data row
|
|
— they're incidental (two `libinfo check path:` continuation lines, one
|
|
WiFi stat line with an embedded tab mid-message). `od -c` on the header
|
|
and data rows confirms the real structure is **space-padded fixed-width
|
|
columns** (`Timestamp`, `Thread`, `Type`, `Activity`, `PID`, `TTL`,
|
|
followed by a free-text `process: message` tail) — visually aligned
|
|
columns that read as tab-separated but aren't.
|
|
|
|
There is no TSV handling anywhere in the codebase today: `src/logfmt.rs`,
|
|
`src/engine.rs`, and `src/ingest.rs` contain zero references to tabs or
|
|
TSV. Format detection is entirely `detect_format` (`src/logfmt.rs:70-78`):
|
|
try JSON, else fall back to `extract_pairs` (`logfmt.rs:45-59`) for
|
|
logfmt, else `"none"` — no third branch exists, and `ottyl_fmt`
|
|
(`src/engine.rs:1005`, filter compilation at `engine.rs:775`, `824`) only
|
|
ever reports one of those three values.
|
|
|
|
This is a duplicate of, not distinct from, ticket 050
|
|
(`tickets/050-structured-header-extraction-and-bounded-logfmt-overfit.md`),
|
|
which already identifies the exact same root cause — `log stream`
|
|
output "is not logfmt at all — it's a fixed-column header... followed by
|
|
a free-text `process: message` tail" — and already scopes a structured-
|
|
header extractor plus the question of whether it becomes a new
|
|
`ottyl_fmt` variant (e.g. `"log_stream"`). The reporter most likely
|
|
visually misread the aligned whitespace columns as tab-separated.
|
|
|
|
## Scope
|
|
|
|
- Do not implement a separate "TSV `ottyl_fmt` type" — there is no
|
|
evidence of genuinely tab-delimited `log stream` output in this
|
|
codebase's fixtures, and building detection for a format that doesn't
|
|
occur would be speculative.
|
|
- Close/merge this wishlist item into ticket 050's existing scope: its
|
|
structured-header extractor for `log stream`-shaped input already
|
|
covers "capturing the format properly" for this input shape.
|
|
- If the user can supply a genuinely tab-delimited sample (e.g. from a
|
|
different `log stream --style` flag, or a shell pipeline that
|
|
reformats the output with real tabs), re-open this as a distinct
|
|
ticket scoped to that concrete input — file:line references above
|
|
should make it easy to confirm one way or the other before implementing
|
|
anything.
|
|
|
|
## Acceptance criteria
|
|
|
|
- No code changes result directly from this ticket; instead, ticket 050
|
|
is updated (or its implementation, when picked up, is confirmed) to
|
|
cover recognizing `log stream`'s fixed-column shape as a known format.
|
|
- If a true TSV sample is later provided, a new ticket is filed against
|
|
it specifically, rather than reopening this one with an unconfirmed
|
|
premise.
|
|
|
|
## Depends on
|
|
|
|
050 (this ticket's concern is already inside 050's scope; treat as
|
|
duplicate/fold-in rather than independent work).
|