Describe the bug
buzz moderation reports --status opne (typo) prints [] and exits 0. That is indistinguishable from “the queue is empty.” A moderator or agent that meant --status open can miss real open reports.
Help text documents four values (open | resolved | dismissed | escalated) but nothing enforces them. The status string is appended to the query as-is. The DB filter is status = $2, so an unknown token matches zero rows and looks like success.
This is the same fail-open class as #6945 (messages get --kinds): invalid CLI input must not look like a successful empty result. Agents cannot inspect stderr interactively.
Steps to reproduce
- With a relay that has at least one open report, run:
buzz moderation reports --status open
Observe: open reports are returned.
- Run:
buzz moderation reports --status opne
- Observe:
[], exit code 0.
- Same with
--status pending, --status OPEN, --status "open ".
Expected behavior
Exit 1 with CliError::Usage, naming the bad value, e.g.
invalid status "opne" — must be one of: open, resolved, dismissed, escalated
Actual behavior
The invalid status is forwarded to GET /moderation/reports?status=opne. The SQL is WHERE … ($2::text IS NULL OR status = $2), so unknown status returns an empty list with no error.
Version and platform
- Buzz CLI: current main
- OS: any
Logs / additional context
crates/buzz-cli/src/commands/moderation.rs (cmd_reports) — no validation; status is interpolated into the path.
crates/buzz-cli/src/lib.rs (ModerationCmd::Reports) — status: Option<String> with no value_parser. Contrast PatchesCmd::Status, which uses value_parser = ["open", "merged", "closed", "draft"], and feed get --types, which rejects unknown tokens before the query.
crates/buzz-db/src/moderation.rs (list_reports) — equality filter, not an enum check.
Suggested fix
Validate before the request (clap value_parser or an explicit allow-list in cmd_reports) and return CliError::Usage on the first unknown value. Do not send the request.
Describe the bug
buzz moderation reports --status opne(typo) prints[]and exits 0. That is indistinguishable from “the queue is empty.” A moderator or agent that meant--status opencan miss real open reports.Help text documents four values (
open | resolved | dismissed | escalated) but nothing enforces them. The status string is appended to the query as-is. The DB filter isstatus = $2, so an unknown token matches zero rows and looks like success.This is the same fail-open class as #6945 (
messages get --kinds): invalid CLI input must not look like a successful empty result. Agents cannot inspect stderr interactively.Steps to reproduce
buzz moderation reports --status openObserve: open reports are returned.
buzz moderation reports --status opne[], exit code 0.--status pending,--status OPEN,--status "open ".Expected behavior
Exit 1 with
CliError::Usage, naming the bad value, e.g.invalid status "opne" — must be one of: open, resolved, dismissed, escalatedActual behavior
The invalid status is forwarded to
GET /moderation/reports?status=opne. The SQL isWHERE … ($2::text IS NULL OR status = $2), so unknown status returns an empty list with no error.Version and platform
Logs / additional context
crates/buzz-cli/src/commands/moderation.rs(cmd_reports) — no validation; status is interpolated into the path.crates/buzz-cli/src/lib.rs(ModerationCmd::Reports) —status: Option<String>with novalue_parser. ContrastPatchesCmd::Status, which usesvalue_parser = ["open", "merged", "closed", "draft"], andfeed get --types, which rejects unknown tokens before the query.crates/buzz-db/src/moderation.rs(list_reports) — equality filter, not an enum check.Suggested fix
Validate before the request (clap
value_parseror an explicit allow-list incmd_reports) and returnCliError::Usageon the first unknown value. Do not send the request.