feat(cli): add bulk cancel, --status filter, fix step JSON hydration#1467
feat(cli): add bulk cancel, --status filter, fix step JSON hydration#1467
Conversation
- Bulk cancel: `workflow cancel --status=running` cancels all matching runs with confirmation prompt (bypass with -y). Supports --workflowName and --limit. - Status filter: `workflow inspect runs --status=completed` filters by status. - Fix: `inspect steps --withData --json` now shows hydrated values, not raw bytes. Signed-off-by: Lucas Ralph <lucas@vercel.com> Signed-off-by: Lucas Ralph <lucas.ralph@vercel.com>
🦋 Changeset detectedLatest commit: 471fcce The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
cc @vercel/workflow — ready for review when you get a chance |
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
❌ Some benchmark jobs failed:
Check the workflow run for details. |
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🌍 Community Worlds (56 failed)mongodb (3 failed):
redis (2 failed):
turso (51 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
|
| // Non-TTY: skip confirmation | ||
| if (!process.stdin.isTTY) { | ||
| return true; |
There was a problem hiding this comment.
@Ralph-20 I assumed this was intentional and am fine with it, but let me know if not. Once confirmed, I'll merge
Description
Three changes to the CLI:
1. Bulk cancel (
workflow cancel --status=<status>)--statusand/or--workflowNamefilters-y/--confirmfor CI)--limitcontrols max runs per batch (default 50), warns if more match2. Status filter for inspect runs (
--status)--statusflag onworkflow inspect runsListWorkflowRunsParams.statusin World API3. Fix: step I/O hydration in JSON output
workflow inspect steps --withData --jsonnow shows hydrated JS values{"0":100,...})inspect runs --jsonWhy: Needed to manually cancel 40+ stuck runs one at a time. The World API already supports status filtering — the CLI just didn't expose it.
CLI Output Examples
Bulk cancel 3 running workflows:
hasMore warning (more runs than --limit):
No matching runs:
Error — no filters provided:
--status filter on inspect runs:
Step hydration fix (--json shows actual values, not byte arrays):
{ "stepName": "step//./workflows/98_duplicate_case//add", "status": "completed", "input": { "args": [205, 5] }, "output": 210 }Previously
"output"would show{"0": 210}(raw devalue bytes).How did you test your changes?
Reusable E2E test script (
packages/cli/test-bulk-cancel.sh) against local world backend — 8/8 passing:--statusfilter on inspect runs--status=running(3 workflows)--workflowNamefilterhasMorewarning with--limit=1Run with:
cd packages/cli && pnpm build && bash test-bulk-cancel.sh(requires workbench on :3000)Known limitations / follow-ups
--workflowNamerequires full WDK path —sleepingWorkflowwon't matchworkflow//./workflows/99_e2e//sleepingWorkflow. The World API does exact match. Could add substring/suffix matching in a follow-up.-yauto-confirm. ThepromptConfirm()function is standard readline, but no automated TTY test exists.--backend local— Vercel backend uses different workflow name formats. Status filter should work identically since it passes through to the same World API.cancel --status=completedlists runs and attempts cancel, but each cancel fails with "Cannot transition from terminal state". Could filter these out upfront or add a pre-check.PR Checklist - Required to merge
pnpm changesetwas run to create a changelog for this PR@vercel/workflowin a comment once the PR is ready🤖 Generated with Claude Code