Support re-triggering a failed run from the Hackbot UI - #6449
Support re-triggering a failed run from the Hackbot UI#6449suhaibmujahid wants to merge 5 commits into
Conversation
Failed runs previously had to be retried by re-entering every input in the trigger form, which is tedious for agents with non-trivial inputs such as build-repair's failure_tasks JSON. Add a "Re-run with same inputs" button to the run detail page for failed and timed-out runs. It posts to a new /api/runs/:runId/retrigger route that reads the stored run server-side and starts a fresh run with the same agent and inputs, attributed to the signed-in user. The original run is left untouched, and the new run gets its own id and results prefix. Key RunDetail on the run id so following the new run remounts with fresh state instead of rendering the previous run's doc, error and actions.
There was a problem hiding this comment.
Pull request overview
This PR adds “re-run” support to Hackbot UI for failed runs by introducing a dedicated API endpoint that creates a new run using the failed run’s stored inputs, and wiring that up to the run detail UI.
Changes:
- Add an
isFailedhelper for consistent “failed or timed out” status checks across UI and API code. - Add
POST /api/runs/:runId/retriggerto create a new run with the same inputs as a failed run (attributed to the currently signed-in user). - Add a “Re-run with same inputs” button on the run detail page and ensure state resets cleanly when navigating to the newly created run.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| services/hackbot-ui/lib/types.ts | Adds isFailed helper and reuses existing RunStatus/RunRef types for retrigger flow. |
| services/hackbot-ui/components/RunDetail.tsx | Adds UI/button + client-side POST to retrigger endpoint and navigates to the newly created run. |
| services/hackbot-ui/components/RecentRuns.tsx | Refactors failed-status checks to use isFailed helper. |
| services/hackbot-ui/app/runs/[runId]/page.tsx | Forces RunDetail remount on runId changes to clear transient UI state after navigation. |
| services/hackbot-ui/app/api/runs/[runId]/retrigger/route.ts | Implements the retrigger API route that re-creates a run from a failed run’s stored inputs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
padenot
left a comment
padenot
left a comment
There was a problem hiding this comment.
Some comments, this largely does what it says it does and what is needed.
| const doc = await getRun(runId); | ||
| if (!isFailed(doc.status)) { | ||
| return NextResponse.json( | ||
| { error: `Only failed runs can be re-run (this one is ${doc.status})` }, |
There was a problem hiding this comment.
Why? What if you're not happy with the outcome and want to roll the dice again.
This is probably better served by a "Clone" action that let you edit it (change prompt, change model, etc.)
There was a problem hiding this comment.
You can still trigger it again manually. But supporting that with a button could be tricky without accommodating for cases where re-triggering have side effects that might create noise, like double posting on Bugzilla, or submitting two patches for the same bug.
This is probably better served by a "Clone" action that let you edit it (change prompt, change model, etc.)
I agree!
| <Link href="/" className="muted"> | ||
| ← all runs | ||
| </Link> | ||
| <div style={{ display: "flex", alignItems: "center", gap: 12 }}> |
There was a problem hiding this comment.
Do we typically do inline style here? I know some framework somehow like that.
There was a problem hiding this comment.
Next.js supports CSS-in-JS nicely, but I will refactor that at some point to make a more consistent styling, maybe with Tailwind.
| > | ||
| {retriggering ? "Re-running…" : "Re-run with same inputs"} | ||
| </button> | ||
| )} |
There was a problem hiding this comment.
It's nice when UI is always the same look, and you can understand things without thinking. Here, we could have:
- Enabled, "Re-run with same inputs"
- Disabled, "Currently re-running"
- Disabled, "Run succeeded, cannot rerun"
GitHub CI, TreeHerder and others allow to retrigger a run regardless of its final or current state
There was a problem hiding this comment.
Done in 017d7db
GitHub CI, TreeHerder and others allow to retrigger a run regardless of its final or current state
We could do that with the "Clone" workflow that you suggested in #6449 (comment)
|
|
||
| {error && <div className="error-banner">Refresh error: {error}</div>} | ||
| {retriggerError && ( | ||
| <div className="error-banner">Re-run failed: {retriggerError}</div> |
There was a problem hiding this comment.
It's the retrigger that failed, not the re-run, right?
There was a problem hiding this comment.
Good catch, this pr mixes re-run and retrigger, it should be retrigger since it is more accurate.
Instead of hiding the re-run button when a run isn't failed, always render it but disable it and show a contextual label explaining why it can't be triggered (e.g. run succeeded, run in progress).
Relocates the retrigger button from the header into the run details card, leaving the header with only the back link. This makes the action sit closer to the run metadata it applies to and simplifies the top-level layout.
Updates Hackbot UI and API error messaging to consistently use “retrigger” terminology instead of “re-run” for failed runs. This aligns button labels, status text, and failure messages with the retrigger endpoint behavior.
Resolves #6413