From 801967f542c0404a92ca12c077b9995b0a219279 Mon Sep 17 00:00:00 2001 From: ysyneu Date: Wed, 19 Aug 2026 20:35:41 -0700 Subject: [PATCH 1/2] =?UTF-8?q?fix(monit-query):=20diagnose=20never=20acce?= =?UTF-8?q?pted=20mysql=20=E2=80=94=20drop=20it=20from=20flag=20and=20card?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `diagnose` pairs one operation with one set of datasource types: `log_patterns` takes `loki` or `victorialogs`, `metric_trends` takes `prometheus`. There is no third operation, so no other `--ds-type` value can succeed; the server answers with an invalid-parameter error for every other combination. `--ds-type` advertised `mysql` in three places — the flag usage string, the shell-completion enum, and the card's gotcha list. `registerEnumFlag` only feeds completion, so `mysql` was never rejected locally: it travelled to the server and failed there every time. Following either the card or the completion suggestion produced a guaranteed error. Correct all three, and state the operation/type pairing instead of a flat list so the relationship the server actually enforces is visible at the call site. --- internal/cli/monit_query.go | 4 ++-- skills/flashduty/reference/monit-query.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/internal/cli/monit_query.go b/internal/cli/monit_query.go index 17e4b08..9a4341b 100644 --- a/internal/cli/monit_query.go +++ b/internal/cli/monit_query.go @@ -68,9 +68,9 @@ func newMonitQueryDiagnoseCmd() *cobra.Command { }, } - cmd.Flags().StringVar(&dsType, "ds-type", "", "Datasource type: prometheus|victorialogs|loki|mysql (required)") + cmd.Flags().StringVar(&dsType, "ds-type", "", "Datasource type: loki|victorialogs (log_patterns) or prometheus (metric_trends) (required)") cmd.Flags().StringVar(&dsName, "ds-name", "", "Datasource name as configured (required)") - registerEnumFlag(cmd, "ds-type", "prometheus", "victorialogs", "loki", "mysql") + registerEnumFlag(cmd, "ds-type", "prometheus", "victorialogs", "loki") cmd.Flags().StringVar(&timeStart, "time-start", "15m", "Window start: relative duration ('15m'/'1h'), 'now', a date/RFC3339 timestamp, or a unix epoch in seconds or milliseconds") cmd.Flags().StringVar(&timeEnd, "time-end", "now", "Window end: same formats as --time-start; span capped at 6h") cmd.Flags().StringVar(&inputQuery, "input-query", "", "Filter-only log query OR matrix PromQL (required)") diff --git a/skills/flashduty/reference/monit-query.md b/skills/flashduty/reference/monit-query.md index cf45150..84e39ad 100644 --- a/skills/flashduty/reference/monit-query.md +++ b/skills/flashduty/reference/monit-query.md @@ -62,7 +62,7 @@ Raw datasource passthrough (returns values/rows as the datasource itself would) - `rows` has **no time flags** — putting `--time-start` on `rows` is wrong; embed the range in `--expr`. - Empty results = the query genuinely matched nothing in that window — report it, don't widen blindly. - **`diagnose` rejects windows wider than 6 hours outright.** `--time-start`/`--time-end` span is capped at 6h server-side; the default window is the last 15 minutes (`--time-start 15m`, `--time-end now`). Widen within the cap, don't retry past it. -- **`--ds-type` on `diagnose` only accepts `prometheus`, `victorialogs`, `loki`, `mysql`.** `monit datasource-list` can return other types (e.g. `oracle`, `postgres`, `clickhouse`, `elasticsearch`, `sls`) — those are not supported here. +- **`diagnose` pairs one operation with one set of datasource types, and rejects every other combination server-side.** `log_patterns` takes `loki` or `victorialogs`; `metric_trends` takes `prometheus`. There is no third operation, so no other `--ds-type` value can succeed — `mysql`, `oracle`, `postgres`, `clickhouse`, `elasticsearch`, and `sls` all come back as an invalid-parameter error however you pair them. `monit datasource-list` returns those types because `data` supports them; `diagnose` does not. - **Tunables and their caps**: `--max-logs` (default 10000, cap 50000), `--max-patterns` (default 20, cap 50), `--timeout-seconds` (default 25, cap 30). ## Worked example — log-pattern evidence in the last hour From 09fd0edb77a8fe0c5d481e15febc2153c5af859f Mon Sep 17 00:00:00 2001 From: ysyneu Date: Wed, 19 Aug 2026 20:42:47 -0700 Subject: [PATCH 2/2] ci: lint follows go.mod's Go, not whatever is stable today MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit golangci-lint is a prebuilt binary and can only parse source up to the Go release it was built with. `go-version: stable` hands it whatever Go shipped most recently, so Go 1.27.0 going stable made v2.11 (built with go1.26) panic on load — "file requires newer Go version go1.27" — turning lint red on every open PR without a single repo change. ci.yml already resolves Go from go.mod. Do the same here so the linter's toolchain moves when the module moves, and an upstream release cannot break the gate on its own. --- .github/workflows/lint.yml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml index b52caee..74b7d51 100644 --- a/.github/workflows/lint.yml +++ b/.github/workflows/lint.yml @@ -17,7 +17,14 @@ jobs: - uses: actions/checkout@v7 - uses: actions/setup-go@v7 with: - go-version: stable + # Follow the module's own Go, the way ci.yml already does. Chasing + # "stable" means every upstream Go release lands here unannounced, + # and golangci-lint is a prebuilt binary that can only parse source + # up to the Go it was built with: Go 1.27.0 going stable made v2.11 + # (built with go1.26) panic with "file requires newer Go version", + # which is a repo-wide red on every open PR, triggered by nothing in + # the repo. Pinning to go.mod means lint only moves when we move. + go-version-file: "go.mod" - name: golangci-lint uses: golangci/golangci-lint-action@v9 with: