fix(app): show next run time for pending one-shot automations

[Astro-Han]

Summary

Show the "Next run" timestamp on the automation detail page for pending one-shot automations. Previously only recurring definitions surfaced this row; one-shots carried a fireAt field but the UI never displayed it.

No related issue — spotted during UI polish.

Why

A user creating a one-shot automation sees when it repeats ("Once") and its status ("Active"), but has no indication of when it will fire. The data is already on the definition; the detail page just skipped it for the oneshot kind.

Related Issue

None — discovered during automation page polish.

Human Review Status

Pending

Review Focus

• The nextRunLabel memo in automation-detail.tsx now branches on kind: for oneshot it uses fireAt and hides the row once any run exists (the task is spent). Verify this doesn't regress the recurring path.
• The e2e test seeds a oneshot via SDK with fireAt one day out, then asserts the "Next run" text is visible in the detail.

Risk Notes

None.

How To Verify

Typecheck:     bun run typecheck — clean (tsgo -b, 0 errors)
Focused E2E:   playwright test -g "pending one-shot shows its next run" — 1 passed (7.7s)

Screenshots or Recordings

No visible layout change beyond the new row appearing; the row uses the existing InfoRow / DetailGroup components and the same formatTimestamp formatter already used by recurring automations.

Checklist

• Type label — bug applied.
• Routing labels — app applied.
• Priority label — waiting for priority-triage bot.
• Human Review Status above is set to Pending, Approved by @<reviewer>, or Not required: <reason> (default is Pending; "not required" is restricted to bot-authored low-risk PRs).
• I linked the related issue, or stated in Summary why there is no issue.
• I described the review focus and any meaningful risks.
• I replaced the example block in How To Verify with the real verification steps and the key result for each.
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope.
• (conditional) I manually checked visible UI or copy changes when needed, with screenshots or recordings. Leave unticked only if no visible UI or copy changed.
• (conditional) I considered macOS and Windows impact for platform, packaging, updater, signing, paths, shell, or permissions changes. Leave unticked only if no platform/packaging surface was touched.
• (conditional) I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes when relevant. Leave unticked only if none of those surfaces was touched.
• I reviewed the final diff for unrelated changes and suspicious dependency changes.
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English.

Summary by CodeRabbit

• Tests

  • Added e2e tests for one-shot automations: verifies pending scheduled automations display correctly and validates behavior when manual runs occur before scheduled execution time.

• Bug Fixes

  • Fixed next run display to properly handle both recurring and one-shot automations.
  • Improved automation detail view to refresh recent runs when switching between different automations.

[coderabbitai]

Warning

Review limit reached

@Astro-Han, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 39 minutes and 19 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, 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 include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: e6dfbf3c-55e7-4ab4-a29a-0584f36c90d9

📥 Commits

Reviewing files that changed from the base of the PR and between 8821572 and 4740963.

📒 Files selected for processing (1)

• packages/app/e2e/automations/automations-panel.spec.ts

📝 Walkthrough

Walkthrough

This PR makes AutomationDetail reload recent runs when the shown automation changes and updates nextRunLabel to show scheduled fire times for one-shot automations until they have a run on/after fireAt. It also adds E2E tests (and a local oneshot helper) that seed future one-shot automations and verify detail-view behavior, including manual-run interactions.

Changes

One-shot automation display support

Layer / File(s)	Summary
Reactive run loading & next-run label packages/app/src/pages/automations/automation-detail.tsx	Replaced mount-only run loading with a createEffect that reloads recent runs when props.automation changes; reworked nextRunLabel to return undefined when paused, format nextFireAt for recurring automations only when present, and format one-shot fireAt until a run at/after fireAt exists.
One-shot automation e2e tests packages/app/e2e/automations/automations-panel.spec.ts	Added a oneshot(projectID, title, prompt, fireAt) helper to build one-shot create input and two tests: one verifies a future one-shot shows “Once” and “Next run”; the other runs the automation manually before fireAt, confirms “Last run” appears, and asserts “Next run” remains visible.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Astro-Han/pawwork#984: Related backend scheduling/oneshot semantics that these tests and UI behaviors validate.
• Astro-Han/pawwork#1053: Prior changes to Automations panel and detail view that extend UI flows for one-shot behavior.

Poem

🐇 I schedule a spark for a bright future day,
A single fire-time that waits in the fray,
The detail shows once and the next time to be,
Tests click “run now” and still next-run we see,
Hooray — a small rabbit dance for one-shot glee!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: displaying next run time for pending one-shot automations, which matches the core objective of the changeset.
Description check	✅ Passed	The description is comprehensive and follows the template structure with all major sections completed: Summary, Why, Related Issue, Human Review Status, Review Focus, Risk Notes, How To Verify, and Checklist.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/automation-next-run

---

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.}

[github-actions]

Suggested priority: P2 (includes user-path files (packages/app/src/pages/automations/automation-detail.tsx)).

P1/P0 are reserved for maintainer confirmation. Please relabel manually if this is a release blocker, security issue, data-loss risk, or updater/runtime failure.

[gemini-code-assist]

Code Review

This pull request adds support for displaying the next run time of pending one-shot automations in the detail panel, along with a corresponding E2E test. Feedback suggests ensuring that the UI components and state dependencies are consistently derived from a single state signal to prevent state mismatches and layout flashes during asynchronous transitions.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[Astro-Han]

Follow-up fix in 3f46c16: a second-opinion review surfaced a correctness bug in the one-shot next-run logic (independent of the earlier flash thread).

Problem: the label was gated on runs().length > 0, but the scheduler treats a one-shot as spent only once a run lands at or after fireAt (hasRunTriggeredAtOrAfter(id, fireAt), scheduler.ts:106). A manual Run now before fireAt creates a run at now (index.ts:870), which previously hid the next run even though the backend would still fire at the original fireAt — UI and scheduler disagreed.

Fix: gate on runs().some(run => run.triggeredAt >= automation.fireAt), matching the scheduler. Added an e2e: a manual run before fireAt keeps the next run visible. Both one-shot e2e cases pass; typecheck clean.

[Astro-Han]

Second follow-up in 8821572: another independent review flagged a real correctness edge that the first fix exposed.

Problem: the detail view loaded runs only in onMount, but a deep-link jump (the automate tool's open in Automations) swaps props.automation in place without remounting — the detail <Show> is non-keyed (automations-surface.tsx:139, deep-link effect at :59). Now that next-run derives from runs(), switching directly from automation A to an already-fired one-shot B left runs() empty (B's runs never fetched) and persistently showed a spent fireAt. Same root cause also left the existing last-run / recent-runs rows stale on a direct A→B switch.

Fix: move loadRuns into a createEffect keyed on the shown automation, so a direct switch refetches. Verified by the existing second tool card jump e2e (the deep-link A→B path) plus both one-shot cases — full automations-panel suite green locally (12 passed), typecheck clean.

Deferred (advisory): two suggested e2e additions not taken — (a) a spent one-shot hides next run case needs a run with triggeredAt >= fireAt, which means seeding a past fireAt and racing the scheduler (flaky); (b) a paused one-shot case, where the paused early-return is an equivalence-preserving move of pre-existing behavior. Logged here rather than added.