inspect runs --status filter is ignored by the Vercel backend (/v2/runs?status= returns unfiltered results) #3446

Summary

workflow inspect runs --status failed against the Vercel backend returns runs of all statuses. The CLI/client correctly sends the status query param, but the server response is identical regardless of its value — the filter appears to be dropped server-side.

Versions

• workflow 4.8.1 (npx workflow)
• @workflow/cli 4.3.5
• @workflow/world-vercel 4.6.2
• Backend: vercel (default api.vercel.com/v1/workflow proxy)

Repro (CLI)

npx workflow inspect runs --backend vercel --project <project> --team <team> --status failed --limit 5 --json | jq '.data | map(.status)'
# => ["running", "completed", "completed", "completed", "completed"]

Same project, --env preview, comparing two different status values — identical result sets:

--status failed    => ["failed","completed","completed","cancelled","completed", ...]
--status cancelled => ["failed","completed","completed","cancelled","completed", ...]

Client is sending the param

@workflow/world-vercel dist/runs.js sets it before the request:

searchParams.set('status', status);           // runs.js:60
const endpoint = `/v2/runs?${queryString}`;   // runs.js:71

Server-side confirmation (no CLI involved)

Direct curl against the proxy endpoint returns the same unfiltered list for both status values:

curl -s "https://api.vercel.com/v1/workflow/v2/runs?status=failed&limit=5" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "x-vercel-project-id: prj_..." \
  -H "x-vercel-team-id: team_..." \
  -H "x-vercel-environment: preview" | jq '.data | map(.status)'
# => ["failed","completed","completed","cancelled","completed"]  (same for status=cancelled)

So either the api.vercel.com/v1/workflow proxy strips the status query param before forwarding, or the workflow-server /v2/runs handler ignores it.

Expected

Only runs whose status matches the requested value.

Impact

Finding failed runs on a busy production project requires paginating the entire run list and filtering client-side. Also worth noting: --status silently returning unfiltered data is worse than erroring — --limit 2 --status failed confidently returned two completed runs.