Skip to content

feat(web): playground run UX — Save to Runs, auto-start, retry any terminal run - #533

Open
UmutAlihan wants to merge 3 commits into
fabro-sh:mainfrom
UmutAlihan:feat/web-playground-run-ux
Open

feat(web): playground run UX — Save to Runs, auto-start, retry any terminal run#533
UmutAlihan wants to merge 3 commits into
fabro-sh:mainfrom
UmutAlihan:feat/web-playground-run-ux

Conversation

@UmutAlihan

Copy link
Copy Markdown

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/dead runs, 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-status canRetryStatus predicate (mirroring the existing canRetry, which needs the full lifecycle object) for list rows that carry only the flattened lifecycleStatus, 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:

  • Drop [run.sandbox] from 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 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/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, the modal now POSTs /api/v1/runs/{id}/start and 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 — clean
  • bun test — 635 pass / 0 fail

Commits are split per concern for easier review.

ALIHAN DIKEL 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.
@brynary

brynary commented Jul 8, 2026

Copy link
Copy Markdown
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants