Skip to content

fix(api): apply the status filter on run list endpoints - #1086

Open
arberx wants to merge 2 commits into
mainfrom
fix/runs-status-filter
Open

fix(api): apply the status filter on run list endpoints#1086
arberx wants to merge 2 commits into
mainfrom
fix/runs-status-filter

Conversation

@arberx

@arberx arberx commented Sep 3, 2026

Copy link
Copy Markdown
Member

Context

Both run list endpoints typed and parsed a status query parameter but never read it, so GET /runs?status=running returned completed rows. An ignored filter is worse than a rejected one: a caller polling for in-flight work sees a full page of history and cannot tell. This applies the filter, validates it against the run status enum, and mirrors it to the CLI and MCP surfaces so every agent path accepts the same filters.

What ships

  • contracts: runListFilterQuerySchema ({ kind?, status? }) as the single source for route validation and the MCP input.
  • api-routes: GET /runs and GET /projects/:name/runs parse kind and status through that schema, AND them into the where clause, and return 400 VALIDATION_ERROR naming the param and its allowed values on an unknown value (empty string means no filter, as before).
  • openapi: a status query parameter on both list operations; kind and status enums now derive from the contracts schemas. Side effect: the hand-copied kind enum had drifted and lacked four sync kinds, so the SDK type widens (additive). pnpm gen output is deterministic.
  • CLI: canonry runs --status passes through; the server 400 surfaces as VALIDATION_ERROR.
  • MCP: canonry_runs_list accepts optional kind and status.
  • Version 4.181.1: bumped over the threshold, sequenced after feat(health): report build commit and instance identity #1085 (4.181.0). Merge order: feat(health): report build commit and instance identity #1085 first, then this.

Test coverage

  • runs-list-filters.test.ts: for both routes, status=running returns exactly the running rows (including the live repro shape status=running&limit=20), queued and failed return their single seeded rows, status combines with kind as AND, the filter applies before the limit window, an unknown status is a 400 naming the allowed values, and no filter returns everything as before. Both routes' enums are asserted to be the contracts enums.
  • cli-run-contract.test.ts and mcp-registry.test.ts cover the new option and input fields.

Validation

  • pnpm verify green (gen:check, plugin:check, typecheck, lint, 9579 tests).

🤖 Generated with Claude Code

arberx and others added 2 commits September 3, 2026 18:40
GET /runs and GET /projects/:name/runs accepted ?status= and ignored it:
?status=running&limit=20 returned 20 completed rows. Both routes now
filter with eq(runs.status, status), validated against the RunStatuses
enum alongside the existing kind filter; an unknown value is a 400 that
names the param and its allowed values, and an empty value still means
no filter.

The two filters share one contracts schema (runListFilterQuerySchema),
the OpenAPI param enums derive from the same Zod enums (the hand-copied
kind list had fallen four kinds behind RunKinds), and the SDK is
regenerated. canonry runs gains --status and the canonry_runs_list MCP
tool gains kind/status so agents get the same filter as the API.

Patch bump to 4.180.2: the diff exceeds the 100-line threshold.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…y bump

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant