feat(web): playground run UX — Save to Runs, auto-start, retry any terminal run - #533
Open
UmutAlihan wants to merge 3 commits into
Open
feat(web): playground run UX — Save to Runs, auto-start, retry any terminal run#533UmutAlihan wants to merge 3 commits into
UmutAlihan wants to merge 3 commits into
Conversation
added 3 commits
June 27, 2026 01:22
The row actions menu only offered Retry for `failed`/`dead` runs, even though the server re-creates a fresh run from the stored spec for any terminal, non-archived run — succeeded ones included. Add a string-status `canRetryStatus` predicate (mirroring the existing `canRetry`, which needs the full lifecycle object) for list rows that carry only the flattened `lifecycleStatus`, and use it to gate the Retry action. Archived rows surface as `"archived"` and stay excluded.
Add a "Save to Runs" button that creates a run from the current playground draft (create-only — no execution) and surfaces server errors inline, alongside the existing Download/Run-for-real actions. Two server-compatibility fixes make playground-built manifests actually accepted at run creation: - Drop `[run.sandbox]` from the generated workflow.toml. The server parses that file into a `RunLayer` with `deny_unknown_fields` and no `sandbox` field, so the section made the whole manifest unparseable (400). Sandbox selection moves to project.toml's `[environments.default]`, the supported home for it. - Clamp the goal-derived run title to the server's 100 code-point limit (counting by code point to match Rust's `chars().count()`), so long goals no longer get rejected.
The modal copy promises to redirect "to its run page when it starts",
but `POST /api/v1/runs` only creates the run in `submitted` status and
the run page has no start affordance — so launched runs sat `submitted`
forever.
After creating the run, POST `/api/v1/runs/{id}/start` and only redirect
once it has actually started. A start failure is surfaced inline (e.g.
409 "not startable") instead of silently redirecting to a stuck run.
Member
|
Hi @UmutAlihan -- Thanks for this contribution. We are doing some additional work on the Playground soon and will incorporate this direction when we circle back to it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three small, independent web-only improvements to the run UX, each with tests. No backend changes.
1. Retry any terminal run from the runs list
The row actions menu only offered Retry for
failed/deadruns, even though the server re-creates a fresh run from the stored spec for any terminal, non-archived run — succeeded ones included. Adds a string-statuscanRetryStatuspredicate (mirroring the existingcanRetry, which needs the full lifecycle object) for list rows that carry only the flattenedlifecycleStatus, and uses it to gate the action. Archived rows surface as"archived"and stay excluded.2. "Save to Runs" in the playground + run-manifest fixes
Adds a Save to Runs button that creates a run from the current draft (create-only — no execution) and surfaces server errors inline. Two compatibility fixes make playground-built manifests actually accepted at run creation:
[run.sandbox]from generatedworkflow.toml. The server parses that file into aRunLayerwithdeny_unknown_fieldsand nosandboxfield, so the section made the whole manifest unparseable (400). Sandbox selection moves toproject.toml's[environments.default], the supported home for it.chars().count()), so long goals are no longer rejected.3. "Run for real" actually starts the run
The modal copy promises to redirect "to its run page when it starts", but
POST /api/v1/runsonly creates the run insubmittedstatus and the run page has no start affordance — so launched runs satsubmittedforever. After creating the run, the modal now POSTs/api/v1/runs/{id}/startand only redirects once it has started; a start failure (e.g. 409 "not startable") is surfaced inline instead of redirecting to a stuck run.Testing
bun run typecheck— cleanbun test— 635 pass / 0 failCommits are split per concern for easier review.