talm dmesg: --tail=N produces a cryptic ParseBool error; cushion the footgun in the wrapper #195

talm dmesg --tail=3 fails with:

invalid argument "3" for "--tail" flag: strconv.ParseBool: parsing "3": invalid syntax

This is upstream behaviour: talosctl defines --tail as a boolean toggling tail-mode for the --follow stream, not as a line count. The gRPC method signature Dmesg(ctx, follow, tail bool) reflects the same shape; there's no server-side line-count parameter to forward to.

Operator confusion source: the flag name --tail mirrors tail(1)'s -n <N> semantics, which is the default mental model when an operator wants "the last N lines". An operator typing --tail=3 is asking for line count, not tail-mode. The strconv.ParseBool error message gives no clue about what --tail actually does.

Upstream classifies as deliberate API — not a bug, just consistent gRPC shape. The flag works exactly as documented in its help text. But the footgun lands operators in a cryptic error and is exactly the class of thing talm should help defuse.

Options

1. Pre-flight hint in the talm wrapper. Detect --tail=<value-that-fails-ParseBool> and rewrite the error with a clear hint:

   talm dmesg: --tail is a boolean toggling tail-mode for --follow, not a line count.
   For the last N lines, run:
       talm dmesg --nodes <node> | tail -n 3
   To stream only new messages on a follow:
       talm dmesg --follow --tail
   

2. Client-side --tail-lines=N flag. A new talm-owned flag that buffers the dmesg stream and emits only the last N lines client-side. Cleaner UX, but introduces talm-specific surface distinct from upstream; future readers of talm dmesg --help see flags that don't exist in talosctl dmesg.

3. Documentation-only. Update --help for the wrapped dmesg command to explicitly note that --tail takes no value and that line-count lives in pipe-to-tail. Cheapest, doesn't help operators who don't read help before typing.

Option 1 is the lowest-cost and addresses the actual harm: the operator gets a clear next step instead of a cryptic ParseBool error. Option 2 gives the best UX but accepts talm-specific divergence from upstream.

Why not upstream

The upstream definition is internally consistent: BoolVarP(&dmesgTail, "tail", "", false, "specify if only new messages should be sent (makes sense only when combined with --follow)") in siderolabs/talos — cmd/talosctl/cmd/talos/dmesg.go. The gRPC Dmesg(ctx, follow, tail bool) API matches. Filing against siderolabs/talos would ask them to either rename a stable flag (breaking) or break their wire API (also breaking). Mitigation belongs in talm's wrapper layer.

Reproducer

$ talm dmesg --tail=3
Error: invalid argument "3" for "--tail" flag: strconv.ParseBool: parsing "3": invalid syntax
$ echo $?
1