Found while implementing #1605's POST /abort, verified live in Obsidian 1.13.0.
quickadd:interactive promises to forward a run's prompts to the connected client. It does
that for every script prompt (quickAddApi.*), the formatter's {{VALUE}}/{{FIELD}}
prompts and the one-page preflight - each of those consults
choiceExecutor.promptProvider. Several prompts the engines open do not:
src/engine/TemplateChoiceEngine.ts - the "file already exists" chooser
src/engine/TemplateEngine.ts - the folder chooser
src/engine/CaptureChoiceEngine.ts - the capture-target pickers
git grep promptProvider -- src shows the provider is read in quickAddApi.ts,
completeFormatter.ts, runOnePagePreflight.ts, AIAssistant.ts and
MacroChoiceEngine.ts only. registerQuickAddCliHandlers sets
choiceExecutor.interactive = true for an interactive run, which only disables the
non-interactive guards - so these open a real modal.
Reproduced. A Template choice with setFileExistsBehavior: true whose target note
already exists, run as quickadd:interactive. The client polls and gets nothing; the
Obsidian window shows the chooser:
Append to bottom / Append to top / Overwrite file / Increment trailing number /
Append duplicate suffix / Do nothing
The run then sits there until someone at the desktop answers it, or until the ~75s poll
watchdog gives up. On a headless/Raycast setup - the entire premise of the seam - nobody
answers, and whoever walks past the machine later can complete a run the caller has long
abandoned.
Shape of a fix: route these through promptProvider like the rest. The file-exists
chooser and the folder chooser are both plain suggesters over a fixed list, so they map
onto the existing suggester prompt type with no protocol change. The capture-target
picker allows custom input, which suggester already supports.
Related: POST /abort (#1605) reports {"interrupted":<n>} precisely because it cannot
reach these - 0 means the run was mid-work or blocked on one of them. That limitation
goes away once this is fixed.
Found while implementing #1605's
POST /abort, verified live in Obsidian 1.13.0.quickadd:interactivepromises to forward a run's prompts to the connected client. It doesthat for every script prompt (
quickAddApi.*), the formatter's{{VALUE}}/{{FIELD}}prompts and the one-page preflight - each of those consults
choiceExecutor.promptProvider. Several prompts the engines open do not:src/engine/TemplateChoiceEngine.ts- the "file already exists" choosersrc/engine/TemplateEngine.ts- the folder choosersrc/engine/CaptureChoiceEngine.ts- the capture-target pickersgit grep promptProvider -- srcshows the provider is read inquickAddApi.ts,completeFormatter.ts,runOnePagePreflight.ts,AIAssistant.tsandMacroChoiceEngine.tsonly.registerQuickAddCliHandlerssetschoiceExecutor.interactive = truefor an interactive run, which only disables thenon-interactive guards - so these open a real modal.
Reproduced. A Template choice with
setFileExistsBehavior: truewhose target notealready exists, run as
quickadd:interactive. The client polls and gets nothing; theObsidian window shows the chooser:
The run then sits there until someone at the desktop answers it, or until the ~75s poll
watchdog gives up. On a headless/Raycast setup - the entire premise of the seam - nobody
answers, and whoever walks past the machine later can complete a run the caller has long
abandoned.
Shape of a fix: route these through
promptProviderlike the rest. The file-existschooser and the folder chooser are both plain suggesters over a fixed list, so they map
onto the existing
suggesterprompt type with no protocol change. The capture-targetpicker allows custom input, which
suggesteralready supports.Related:
POST /abort(#1605) reports{"interrupted":<n>}precisely because it cannotreach these -
0means the run was mid-work or blocked on one of them. That limitationgoes away once this is fixed.