Uh oh!
There was an error while loading. Please reload this page.
fix(console): dispatch flow actions from every surface + cover the screen-flow round trip (framework#3528) - #2833
Merged
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub. |
…reen-flow round trip (framework#3528) Follow-up to #2830, which fixed the resume half. These are the two launch-side holes found while mapping every path that dispatches a `type: 'flow'` action — on both, a screen flow could not even be started. **Dashboard header actions never dispatched a flow.** The click handler allow-listed `modal` / `script`; `flow`, `api`, `form` and `navigation` fell through to `console.warn("Unknown header actionType")` and did nothing at all. Everything that is not a raw `url` navigation now goes through the ActionRunner, which owns the type registry — there is nothing for the renderer to second-guess. **The console-root ActionProvider had no handlers.** It exists to give every field widget a modal handler, but an ActionProvider also decides what a `useAction()` consumer below it can dispatch, so any `action:button` outside ObjectView / RecordDetailView / PageView / DeclaredActionsBar bound to a runner that could only open modals: a flow action there failed with "Flow handler not registered", and api/script were equally dead. The root now carries the shared console runtime's api / flow / script handlers plus its confirm / param / result / screen-flow dialogs. `modal` deliberately stays on the client-side `useActionModal` handler — putting it in `handlers` would take precedence over `onModal` and reroute the inline-create affordance to `/api/v1/actions/...`. Both fixes ship with regression tests that were verified to fail without them. The screen-flow seam itself had no coverage, which is how the host-teardown bug survived to production, so this also adds: - `FlowRunner.suspense.test.tsx` — a lazily-loaded screen body must not unwind past the dialog. Reproduces the real shape (lazy body, route-level boundary above the host, host state that must survive) and fails against the pre-boundary runner. - `e2e/live/screen-flow.spec.ts` — the live round trip: a row flow action triggers the run, the paused screen renders, Submit POSTs to `/automation/{flow}/runs/{runId}/resume` with the collected values, and the flow's downstream `update_record` shows up in the list. Verified passing against a real backend (showcase app + console dev server). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LX9ut3MK3KykE11S9bJmv5
os-zhuangforce-pushed
the
claude/screen-flow-submit-resume-v9dqjx
branch
from
July 27, 2026 04:54
581e61a to
b1b9614CompareContributor
❌ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-zhuang
marked this pull request as ready for review
July 27, 2026 04:59
Uh oh!
There was an error while loading. Please reload this page.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Follow-up to #2830 (which fixed the resume half of screen flows). These are the two launch-side holes found while mapping every path that dispatches a
type: 'flow'action — on both, a screen flow could not even be started — plus the test coverage the whole seam was missing.1. Dashboard header actions never dispatched a flow
DashboardRenderer's header click handler allow-listedmodal/script.flow,api,formandnavigationfell through to:…and did nothing at all. Everything that is not a raw
urlnavigation now goes through the ActionRunner, which owns the type registry — there is nothing left for the renderer to second-guess.2. The console-root
<ActionProvider>had no handlersIt exists to give every field widget a modal handler (the lookup "create the referenced record" affordance). But an
ActionProvideralso decides what auseAction()consumer below it can dispatch, and this one carried nohandlersmap — so anyaction:buttonoutside ObjectView / RecordDetailView / PageView / DeclaredActionsBar bound to a runner that could only open modals. Aflowaction there failed with "Flow handler not registered";apiandscriptwere equally dead.The root now carries the shared console runtime's
api/flow/scripthandlers plus its confirm / param / result / screen-flow dialogs.modaldeliberately stays on the client-sideuseActionModalhandler: registering it inhandlerswould take precedence overonModaland reroute the inline-create affordance to/api/v1/actions/....3. Coverage for the screen-flow seam (it had none)
This is how the host-teardown bug in #2830 survived to production: the unit tests stub the runner out of the action runtime, and the runner's own tests feed it a screen directly, so
trigger → dialog → resume → refreshwas only ever exercised by hand.FlowRunner.suspense.test.tsx— a lazily-loaded screen body must not unwind past the dialog. Reproduces the real shape: a lazy body, a route-level<Suspense>above the host, and host state (mount identity) that must survive. Verified to fail against the pre-boundary runner — the route fallback takes over and the host remounts.e2e/live/screen-flow.spec.ts— the live round trip in the house style: a row flow action triggers the run, the paused screen renders, Submit POSTs to/automation/{flow}/runs/{runId}/resumewith the collected values, and the flow's downstreamupdate_recordshows up in the list. Asserts the resume request directly, because the bug class here is a missing request.Test plan
packages/app-shell+packages/plugin-dashboard+apps/consolesuites: 249 files, 2048 tests passed (1 pre-existing skip).Both new regression tests verified to fail without their fix (dashboard: 3 of 4 fail; suspense: route fallback appears).
pnpm --filter @object-ui/app-shell type-checkclean; eslint on all changed files: 0 errors.Live E2E run against a real backend (showcase app on a dev server + console dev server):
Note the live suite is not part of CI (no CI job runs a backend) — same as every existing action/dialog spec in
e2e/live/. The Suspense regression and the dashboard tests do run in CI.🤖 Generated with Claude Code
https://claude.ai/code/session_01LX9ut3MK3KykE11S9bJmv5
Generated by Claude Code