mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
Sami
da612711cf
`--kinds` parsed with `filter_map(|s| s.trim().parse().ok())`, which discarded every unparseable token. An all-garbage list left the default kinds in place and exited 0, so `--kinds '*'`, `--kinds all` and `--kinds ''` all reported success while measuring the DEFAULT narrow list — exactly the blind spot the flag exists to widen. Measured on the prior parser: all three returned rc=0 with kinds [9]. Parsing now returns a usage error naming the offending token, and it happens inside `build_messages_filter` so no code path can reach the wire with a partially discarded list. Verified on the built binary: the six garbage shapes exit 1 with the token quoted, while `9`, `7` and the padded ` 9 , 1984 ` spelling still exit 0. Mutation-checked by restoring the old `filter_map` body — two unit tests fail and the live binary returns to rc=0 with kinds [9] for `*` and `all`. Also documents kind scope in `--help` on both commands, because the CLI cannot report a channel total and a reply count is not an event count. Each now states its default list, that `--kinds` REPLACES rather than extends it, what is EXCLUDED (reactions 7, deletions 5, and edits 40003 on `get`), and that the two commands deliberately use different default lists so their counts are not comparable. `messages get` sends [9,40002,40008,45001,45003]; `messages thread` sends [9,40002,40003,40008,45003]. The reactions gap has a ready-made server-side answer — `include_aux` and `WINDOW_AUX_KINDS` (bridge.rs:383-394, :494) already walk a two-hop reaction/deletion closure with zero call sites in buzz-cli — but plumbing it adds a second surface (aux closure semantics, dedup of two-hop deletions), so it is filed as a follow-up rather than ridden in here. Co-authored-by: Sami <f4a42a97e594b77bdbd8ee35191c8b28a94a4cb871d96f32921558275421fb68@buzz.block.builderlab.xyz> Signed-off-by: Sami <f4a42a97e594b77bdbd8ee35191c8b28a94a4cb871d96f32921558275421fb68@buzz.block.builderlab.xyz>