You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(cloud): fingerprint pod tables by READY+RESTARTS, resolve columns from header (#113)
CloudDistiller treated any table containing NAMESPACE + NAME + STATUS as a pod
table. That is not a fingerprint of anything — it is the common prefix of most
`kubectl get <resource> -A` output. `kubectl get pvc -A` matched it, routed into
distill_kubectl, and every healthy `Bound` claim landed in the catch-all arm and
was reported as an error.
Reproduced against the unfixed distiller, byte-for-byte with the report:
k8s: 35 pods | 0 running, 0 pending, 35 error
Problems: consul (Bound), consul (Bound), ... +30 more
Three changes:
1. is_kubectl_table now requires READY + RESTARTS, which no other `kubectl get`
resource prints.
2. distill_kubectl resolves NAME/STATUS from the header instead of assuming
columns 0 and 2. This was a second, unreported instance of the same bug:
`kubectl get pods -A` also carries a NAMESPACE column, so parts[2] read READY
("1/1") as the status and reported every healthy pod as an error too. A
status outside the known lists now counts as `unknown`, never as `error` — an
unrecognised status is not evidence of a failure. A header missing either
column, or zero parseable rows, returns the input untouched.
3. Columnar listings with no distiller pass through instead of reaching
distill_fallback, which kept 20 lines and dropped the rest with no marker.
Without this, pvc/pv/ns would still lose 15 of 35 rows silently.
Existing kubectl snapshots are unchanged: the non-`-A` fixtures resolve to the
same column indices the old code hardcoded.
Gates ran on rustc 1.94.0, not the pinned 1.97.0 (no rustup locally), so the
clippy result does not predict CI.
Refs #105
0 commit comments