Uh oh!
There was an error while loading. Please reload this page.
feat(cli): bulk-cancel runs in a single operation - #3348
Conversation
🦋 Changeset detectedLatest commit: 62e1e2b 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 |
🧪 E2E Test Results✅ All tests passed E2E Test SummarySummary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
|
Uh oh!
There was an error while loading. Please reload this page.
c64b41a to
d4de36fCompare3e50891 to
c41bdeaCompare📊 Workflow Benchmarkscommit Backend:
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 157366ms → this run 153282ms (Δ -4084ms, -3%) 1020 steps (queue-hop) Cumulative STSO time: main 2996ms → this run 3102ms (Δ +106ms, +4%) 📜 Previous results (2)eb61361Wed, 05 Aug 2026 18:09:19 GMT · run logs
8c796e5Wed, 05 Aug 2026 03:38:47 GMT · run logs
ℹ️ Metric definitions & methodologyThe collapsed STSO distribution section above buckets every step gap of the sequential-steps run (not a sampled window), split by whether the step ending the gap ran inline — in the same warm process as the step before it, so the gap is pure framework overhead — or after a queue-hop — the first step of a fresh process, which pays queue dispatch, client reinit and event-log replay. Bars overlay the two runs: Best/P75/P90/P99 deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window) Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost 🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor ( Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the |
c41bdea to
c1c4924Compareaf4fd04 to
8c796e5Compare
VaguelySerious
left a comment
There was a problem hiding this comment.
AI review: blocking issues found
| for (const run of projected) { | ||
| if (!byRunId.has(run.runId)) byRunId.set(run.runId, run); | ||
| } | ||
| const merged = [...byRunId.values()].sort((a, b) => { |
There was a problem hiding this comment.
AI Review: Blocking
A pending run has no startedAt, so this sort gives it 0 and orders every pending run behind every running run. slice(0, limit) then drops them: workflow cancel -n <name> --limit 50 against 50+ running runs cancels zero pending runs, even though the fan-out fetched them and the default status set includes pending.
Confirmed with a local test driving performBulkCancel with 5 timestamped running runs plus 3 pending runs at --limit 5: cancelRuns receives only the 5 running IDs.
Reruns do reach the pending runs once the running ones drain, so it self-heals, but a user who asks for both statuses and sees the hasMore guidance has no way to infer that one status is systematically starved. Interleaving the per-status pages round-robin before applying the cap keeps both represented and needs no timestamp that pending runs don't have.
There was a problem hiding this comment.
Fixed in e2acdb9c6. The per-status pages are now merged round-robin before applying --limit, while preserving backend order within each status and deduping run IDs. Added the regression case with 5 running + 3 pending runs at limit 5; the selected batch now contains both statuses.
| // One bulk operation: a single backend request on Vercel, or bounded | ||
| // fallback concurrency on local / community worlds. | ||
| const result = await cancelRuns( |
There was a problem hiding this comment.
AI Review: Nit
cancelRuns accepts cancelReason and it is persisted on the run. Stamping something like workflow cancel CLI here would let anyone reading a run afterwards tell an operator bulk cancel apart from an in-workflow one.
There was a problem hiding this comment.
Fixed in e2acdb9c6. CLI-triggered cancellation now supplies Cancelled via Workflow CLI as cancelReason for both single-run cancelRun and bulk cancelRuns. Tests cover propagation through the bulk fast path and the local/community fallback event path.
Replace the per-run cancel loop in `workflow cancel` with one `cancelRuns` call, validate `--limit` (1-500), print a compact outcome summary with per-run lines for surfaced failures, and exit nonzero only when a run fails. The bulk logic lives in a dependency-injected `performBulkCancel` helper so it is unit-testable without an oclif harness. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
No backport to This is feature work: it adds a bulk-cancel mode to To override, re-run the Backport to stable workflow manually via |
What
workflow cancelgains a bulk mode: cancel runs matched by--status(pending or running) or--workflowNamein one operation. Adds--limit(1–500), an interactive confirmation prompt (-y/--confirmto skip), a compact outcome summary, and a nonzero exit only when a run genuinely fails.Why
Operators need to cancel batches of stuck or runaway runs without scripting one CLI call per run.
Docs
This API is v5-only; only v5 docs are updated (
configuration/cli-and-web-ui.mdx). No v4 docs are changed.Stacked on #3347.
🤖 Generated with Claude Code