Follow-up from #5711 ("Worth checking in the same sweep whether record:alert's CTA path … shares the gap").
The observation
record-alert.tsx's own header comment claims its CTA runs through "the same pipeline that record:quick_actions uses" — and it does: it calls useActionEngine (packages/plugin-detail/src/renderers/record-alert.tsx), which reuses the surrounding <ActionProvider>'s shared ActionRunner when one is mounted and falls back to a local, unwired one otherwise (packages/react/src/hooks/useActionEngine.ts). resultDialog is honoured centrally in ActionRunner.handlePostExecution — same mechanism #5711 pins for record:quick_actions.
Checked (not recalled): grep -in "resultDialog\|ActionProvider" packages/plugin-detail/src/renderers/__tests__/record-alert*.test.tsx → only one hit, a comment in record-alert.test.tsx noting the renderer "require[s] a live provider tree (RecordContext, ActionProvider, …)" — no assertion anywhere in the four record-alert*.test.tsx files that a handler registered on an ambient <ActionProvider> is actually reachable from record:alert's CTA button, and no assertion of the negative (no-provider) leg either.
Why it matters
Identical failure shape to #5711: if a refactor ever caused record:alert's CTA to fall back to a local runner, an action declaring resultDialog would keep reporting success, the success toast would stay suppressed (suppression is unconditional on resultDialog being set, independent of whether a handler exists), and the user would see nothing. Only trace is a console.warn.
Suggested shape
Mirror #5711's PR (packages/plugin-detail/src/renderers/__tests__/record-quick-actions.resultDialog.test.tsx): mount record:alert under <ActionProvider onResultDialog onToast> with a CTA action declaring resultDialog, assert the dialog opens with the response value and the toast is suppressed; plus the negative leg with no provider.
observation-class, unassigned.
Follow-up from #5711 ("Worth checking in the same sweep whether
record:alert's CTA path … shares the gap").The observation
record-alert.tsx's own header comment claims its CTA runs through "the same pipeline thatrecord:quick_actionsuses" — and it does: it callsuseActionEngine(packages/plugin-detail/src/renderers/record-alert.tsx), which reuses the surrounding<ActionProvider>'s sharedActionRunnerwhen one is mounted and falls back to a local, unwired one otherwise (packages/react/src/hooks/useActionEngine.ts).resultDialogis honoured centrally inActionRunner.handlePostExecution— same mechanism #5711 pins forrecord:quick_actions.Checked (not recalled):
grep -in "resultDialog\|ActionProvider" packages/plugin-detail/src/renderers/__tests__/record-alert*.test.tsx→ only one hit, a comment inrecord-alert.test.tsxnoting the renderer "require[s] a live provider tree (RecordContext, ActionProvider, …)" — no assertion anywhere in the fourrecord-alert*.test.tsxfiles that a handler registered on an ambient<ActionProvider>is actually reachable fromrecord:alert's CTA button, and no assertion of the negative (no-provider) leg either.Why it matters
Identical failure shape to #5711: if a refactor ever caused
record:alert's CTA to fall back to a local runner, an action declaringresultDialogwould keep reporting success, the success toast would stay suppressed (suppression is unconditional onresultDialogbeing set, independent of whether a handler exists), and the user would see nothing. Only trace is aconsole.warn.Suggested shape
Mirror #5711's PR (
packages/plugin-detail/src/renderers/__tests__/record-quick-actions.resultDialog.test.tsx): mountrecord:alertunder<ActionProvider onResultDialog onToast>with a CTA action declaringresultDialog, assert the dialog opens with the response value and the toast is suppressed; plus the negative leg with no provider.observation-class, unassigned.