feat(jobs): per-cmd live counters + kill button on Jobs page

[yukimemi]

Summary

PR γ of the v0.30 kill-UX trio (PR α + β still TODO — agent events.started wire + Activity Running tab). γ stands alone so it ships first; per the design discussion the right home for per-cmd aggregate counters is the Jobs catalog page, not Activity (which is per-PC).

What operators see

The Jobs page table gains a new live column. For each cmd it shows:

• running: N (violet) — at least one PC has reported back, more results still in flight
• pending: N (secondary) — fan-out published, no result back yet
• — when both are zero (idle)

And a new per-row Kill button (danger, Skull icon):

• Greyed out when live.running === 0 so operators don't fire no-ops
• Confirm dialog spells out the kill ≠ revoke distinction: "this does NOT block the next schedule tick — click revoke alongside if you want to stop new fires too"
• Backed by the existing POST /api/jobs/{cmd_id}/kill route (v0.29 — was a silent no-op before that)

Backend

GET /api/jobs response gains live: { running, pending } per row. Aggregated via a single GROUP BY job_id query against the v0.29 executions table. serde(flatten) keeps existing Manifest fields at JSON root so the SPA's existing job.id / job.version / job.execute reads still work — live is purely additive.

Resilient: live count query failure falls back to zeros (warn! logged) so a SQLite hiccup doesn't take the whole Jobs page down.

Test plan

• cargo test --workspace — 181 passing (3 new for fetch_live_counts)
• cargo clippy --workspace --all-targets -- -D warnings clean
• cargo fmt --all -- --check clean
• tsc --noEmit SPA clean
• Manual: fire kanade exec inventory-hw against multi-PC, observe Jobs page chip transitions pending → running → idle
• Manual: with running execs, click Kill — verify children terminate and chip clears

🤖 Generated with Claude Code

[coderabbitai]

Warning

Rate limit exceeded

@yukimemi has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 59 minutes and 33 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 69a67c87-fa96-4da6-b35c-64a5a3901dde

📥 Commits

Reviewing files that changed from the base of the PR and between 1cac552 and 1a4487b.

📒 Files selected for processing (2)

• crates/kanade-backend/src/api/jobs.rs
• crates/kanade-backend/web/src/pages/Jobs.tsx

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/jobs-live-aggregate-and-kill

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request introduces in-flight execution counters to the Jobs page, allowing operators to monitor "running" and "pending" tasks. It also adds a "kill" action to terminate all active executions for a specific job. Review feedback recommends optimizing the backend aggregation query by filtering for relevant statuses and updating the frontend logic to ensure the "kill" button and its associated UI messages correctly account for both "running" and "pending" states.

[gemini-code-assist]

The query in fetch_live_counts currently scans the entire executions table to perform the aggregation. As the history of executions grows, this will become a performance bottleneck for the Jobs page. Since we only care about 'running' and 'pending' states, adding a WHERE clause will significantly improve performance, especially if an index exists on the status column.

Suggested change

	let rows = sqlx::query(
	"SELECT job_id,
	SUM(CASE WHEN status = 'running' THEN 1 ELSE 0 END) AS running,
	SUM(CASE WHEN status = 'pending' THEN 1 ELSE 0 END) AS pending
	FROM executions
	GROUP BY job_id",
	)
	let rows = sqlx::query(
	"SELECT job_id,
	SUM(CASE WHEN status = 'running' THEN 1 ELSE 0 END) AS running,
	SUM(CASE WHEN status = 'pending' THEN 1 ELSE 0 END) AS pending
	FROM executions
	WHERE status IN ('running', 'pending')
	GROUP BY job_id",
	)

[gemini-code-assist]

The kill button is currently disabled if live.running is 0, even if there are pending executions. Since the backend kill handler (and the operator's intent) includes pending executions (those that have been published but haven't reported back yet), the button should be enabled if either count is greater than zero. This allows operators to abort a job immediately after firing it before any results land.

Suggested change

	disabled={pendingKill.has(j.id) || j.live.running === 0}
	disabled={pendingKill.has(j.id) || (j.live.running + j.live.pending) === 0}

[gemini-code-assist]

The confirmation message only mentions the running count, which is misleading because the kill action targets all in-flight executions, including those in the pending state. It should reflect the total number of runs that will be affected.

Suggested change

	`Kill all running runs of ${j.id}?\n\n` +
	`${j.live.running} run${j.live.running === 1 ? '' : 's'} currently in flight. ` +
	`Kill all running runs of ${j.id}?\n\n` +
	`${j.live.running + j.live.pending} run${(j.live.running + j.live.pending) === 1 ? '' : 's'} currently in flight. ` +

[gemini-code-assist]

The button's tooltip should also account for both running and pending executions to accurately describe what the action will terminate.

Suggested change

	title={
	j.live.running === 0
	? 'Nothing running for this job right now'
	: `Terminate ${j.live.running} in-flight run${j.live.running === 1 ? '' : 's'}`
	}
	title={
	(j.live.running + j.live.pending) === 0
	? 'Nothing running for this job right now'
	: `Terminate ${j.live.running + j.live.pending} in-flight run${(j.live.running + j.live.pending) === 1 ? '' : 's'}`
	}

[yukimemi]

Round-1 Gemini fixes applied (force-push → 1a4487b):

medium #1 (jobs.rs:197): added WHERE status IN ('running', 'pending') to the aggregation query — filters before the GROUP BY so SQLite skips the completed-execs tail instead of summing CASE-zeros across it. The caller's unwrap_or_default() fallback already handled the now-omitted empty groups.

medium #2, #3, #4 (Jobs.tsx kill button): the SPA had running === 0 everywhere, but the backend /api/jobs/{id}/kill handler SELECTs status IN ('pending', 'running') — so a just-fired but not-yet-reported-back exec IS killable. Unified all three sites (disable predicate, confirm dialog count + breakdown, tooltip) to running + pending. Confirm message now shows the breakdown explicitly: "X runs currently in flight (running: A, pending: B)".

cargo test --workspace: 181 passing. clippy + fmt + tsc clean.