feat: add wmill job rerun subcommand

[hugocasa]

Summary

Adds two CLI subcommands for re-running completed jobs from the command line:

• wmill job rerun <id> — equivalent of the frontend "Run again with same args" button. Wraps batchReRunJobs for the single-job case.
• wmill job restart <id> --step <step-id> [--iteration <n>] — restart a completed flow at a top-level step. Wraps restartFlowAtStep. EE-only feature on the backend.

Both print the new job UUID on stdout so they compose, e.g. wmill job rerun <id> | xargs wmill job logs.

Changes

• rerun: sends { job_ids: [<id>], script_options_by_path: {}, flow_options_by_path: {} } (defaults match the frontend button's "with same args" semantics). Parses the newline-separated stream response, surfaces Error: lines via log.error, exits non-zero if no new UUID was returned.
• restart: sends { step_id, branch_or_iteration_n? }. Same wire format / body shape as FlowRestartButton.svelte. Required --step, optional --iteration for top-level branchall / for-loop iteration restart.
• Mentions added to the Debugging Jobs section of cli/src/guidance/core.ts.
• Regenerated system_prompts/auto-generated/ and cli/src/guidance/skills.gen.ts via python system_prompts/generate.py (required by AGENTS.md since cli/src/commands/ changed).

Out of scope

restartFlowAtStep also accepts a nested_path array for restarting inside nested containers (BranchOne / ForLoop iteration / Subflow). CLI ergonomics for nested paths are awkward (would need either a JSON flag or a repeatable --nested-step parser) and demand is low — for nested restart, use the UI.

Test plan

• wmill job rerun <id> against a recently completed script job prints a new job UUID; piping into wmill job get <id> shows the new job ran with the same args
• wmill job rerun <id> against a flow job works the same way (new flow run id, same args)
• wmill job --help lists both rerun and restart
• wmill job rerun <unknown-uuid> exits non-zero with Failed to re-run job <id>
• wmill job restart <flow-id> --step <step-id> on an EE backend prints a new flow UUID; flow resumes from the chosen step
• wmill job restart <flow-id> --step <step-id> --iteration <n> resumes a top-level for-loop / branchall at iteration n
• wmill job restart <id> without --step exits non-zero with a usage error

[cloudflare-workers-and-pages]

Deploying windmill with    Cloudflare Pages

Latest commit:	998f1e2
Status:	✅  Deploy successful!
Preview URL:	https://d49ac799.windmill.pages.dev
Branch Preview URL:	https://wmill-job-rerun.windmill.pages.dev

View logs

[claude]

Claude finished @hugocasa's task in 3m 47s —— View job

---

Review — PR #9275

Mergeable, but should ideally address nits: (1) restart help string doesn't mention EE-only requirement, (2) job --help test in cli/test/job_commands.test.ts:211 doesn't assert the new subcommands appear, (3) two manual-test boxes for restart remain unchecked in the PR description.

cc @hugocasa

---

Code review

The wire format for both commands matches the frontend exactly:

• rerun mirrors RunsPage.svelte:356-385 — same body shape (job_ids / script_options_by_path / flow_options_by_path), same line-by-line parsing of the text/event-stream response with Error:-prefix detection (cli/src/commands/job/job.ts:399-404).
• restart mirrors FlowRestartButton.svelte:163-172 — same { step_id, branch_or_iteration_n } body, and the backend's EE handler returns (StatusCode::CREATED, uuid.to_string()) so a single UUID is the correct return (backend/windmill-api/src/jobs.rs:4416).
• The streaming-response parser correctly handles the documented "stream of created job uuids separated by \n. Lines may start with 'Error:'" contract from openapi.yaml.
• log.error does not honor setSilent (cli/src/core/log.ts:29-31), so the early log.setSilent(true) on line 383 still lets error lines through to stderr — good.
• The single-job rerun against an unknown UUID correctly throws because the backend SQL filter (backend/windmill-api/src/jobs.rs:3790-3792) emits nothing for non-matching ids, leaving newIds.length === 0.
• AGENTS.md compliance: the regenerated system_prompts/auto-generated/ and cli/src/guidance/skills.gen.ts are present, as required when touching cli/src/commands/. Good.

No bugs, security issues, or perf concerns found. Both new commands follow the existing cancel/result patterns in the same file.

Findings

• P2 — restart description silently fails on CE (cli/src/commands/job/job.ts:478-479)
  The help string says "Restart a completed flow at a given top-level step. Prints the new flow job UUID on stdout.", but backend/windmill-api/src/jobs.rs:4098-4100 returns "Restarting a flow is a feature only available in enterprise version" on the CE handler. Worth adding (EE only) to the description and/or the guidance line in cli/src/guidance/core.ts:69 so users don't get blindsided. Fix this →

• P2 — job --help test doesn't assert the new subcommands (cli/test/job_commands.test.ts:211-224)
  The existing "job --help shows all subcommands" test checks for list, get, result, logs, cancel. Two new subcommands ship without an analogous assertion; easy to add. Fix this →

Test coverage

• Backend: no backend changes — both endpoints already existed (batch_rerun_jobs, restart_flow). Nothing new to test there.
• CLI: existing cli/test/job_commands.test.ts has integration tests for list/get/result/logs/cancel. Adding rerun/restart to the help-output assertion is the minimum; a full integration test that re-runs a real job and validates the new UUID would be even better, mirroring how job get is tested at line 227.
• Manual verification still needed before merge: two items in the PR description are unchecked — running wmill job restart <flow-id> --step <step-id> on an EE backend, and the --iteration <n> variant against a top-level for-loop or branchall. Both need an EE backend, which is the gating factor.
  · Branch

[cubic-dev-ai]

No issues found across 6 files

_{Re-trigger cubic}

[github-actions]

Codex Review

Good to merge

No issues found. Checked for bugs, security, and AGENTS.md compliance.

Test coverage

CLI and generated guidance/docs only. I did not see new automated CLI tests, but the PR wires existing backend endpoints that already have backend coverage, and the PR body lists relevant manual CLI checks.

Manual verification before merge should cover wmill job rerun <completed-job-id> printing a new UUID, wmill job restart <flow-job-id> --step <step-id> on an EE backend printing a new flow UUID, wmill job restart <id> without --step failing with a usage error, and wmill job --help listing both new commands.