Found while fixing #1574.
src/interactive/promptProvider.ts opens by claiming:
Each method returns exactly what its in-app counterpart returns, so a script cannot tell it
was driven remotely.
infoDialog breaks that, in the opposite direction from the rest of the seam. Remotely,
replying {"cancelled":true} to an info prompt rejects with UserCancelError and aborts
the run. In-app, GenericInfoDialog resolves on every close path and has no reject path
at all, so it can never abort anything.
Concrete divergence: a Raycast-style client shows an info panel; the user presses Escape - the
only gesture an info panel affords - and the client maps that to a cancel. The macro's
remaining steps never run, and the client gets {"kind":"error","error":"Input cancelled by user"}. The identical choice run in the app continues past the OK button.
#1574 documented this rather than changing it, on the grounds that cancelling is a client's
only explicit way to bail out mid-run. A reviewer pointed out that justification is weaker
than it looks: the poll watchdog (POLL_TIMEOUT_MS, 75s) already aborts a run whose client
stops polling, so a bail-out exists - it is just slow and implicit.
Shape of a fix: give the protocol an explicit session-abort route (e.g.
POST /abort?session=…), then make an info cancel resolve like the in-app dialog, so the
parity claim in that docstring becomes true without removing a capability. Doing only the
second half would take the bail-out away with nothing to replace it, which is why #1574 left
it alone.
Found while fixing #1574.
src/interactive/promptProvider.tsopens by claiming:infoDialogbreaks that, in the opposite direction from the rest of the seam. Remotely,replying
{"cancelled":true}to aninfoprompt rejects withUserCancelErrorand abortsthe run. In-app,
GenericInfoDialogresolves on every close path and has no reject pathat all, so it can never abort anything.
Concrete divergence: a Raycast-style client shows an info panel; the user presses Escape - the
only gesture an info panel affords - and the client maps that to a cancel. The macro's
remaining steps never run, and the client gets
{"kind":"error","error":"Input cancelled by user"}. The identical choice run in the app continues past the OK button.#1574 documented this rather than changing it, on the grounds that cancelling is a client's
only explicit way to bail out mid-run. A reviewer pointed out that justification is weaker
than it looks: the poll watchdog (
POLL_TIMEOUT_MS, 75s) already aborts a run whose clientstops polling, so a bail-out exists - it is just slow and implicit.
Shape of a fix: give the protocol an explicit session-abort route (e.g.
POST /abort?session=…), then make aninfocancel resolve like the in-app dialog, so theparity claim in that docstring becomes true without removing a capability. Doing only the
second half would take the bail-out away with nothing to replace it, which is why #1574 left
it alone.