coreapp-packaged-indexing-diagnostics-probe's --runMaintenanceAction always throws: the preload has no ipcRenderer.invoke

[TalexDreamSoul]

Found by trying to use it. --runMaintenanceAction scan|reconcile|reset cannot work against the current preload, and fails with the probe's own "unavailable" error rather than anything that points at the cause.

The mismatch

coreapp-packaged-indexing-diagnostics-probe.ts:runMaintenanceActionExpression builds:

const invoke = window.electron?.ipcRenderer?.invoke?.bind(window.electron.ipcRenderer)
if (!invoke) throw new Error('window.electron.ipcRenderer.invoke is unavailable')
return await invoke('app:indexed-source:scan', { sourceId, reason: 'manual-rebuild' })

The preload exposes no such method. apps/core-app/src/preload/index.d.ts:14-18:

ipcRenderer: {
  send: (channel: string, ...args: unknown[]) => void
  on: (channel: string, listener: …) => () => void
  removeListener: (channel: string, listener: …) => void
}

Confirmed at runtime, not only from the declaration. Attaching over CDP to a running CoreApp and reading the bridge from both windows:

{"cls":"MacIntel core-box","electron":["ipcRenderer","process"],"ipcKeys":["send","on","removeListener"]}
{"cls":"MacIntel",         "electron":["ipcRenderer","process"],"ipcKeys":["send","on","removeListener"]}

window.electron is present; invoke is not, on either window.

Why it drifted

The preload says so itself (index.ts:166-169):

A narrow replacement for @electron-toolkit/preload's electronAPI. That helper bridges send/on/once/invoke/sendSync/removeAllListeners for any channel name…

So the surface was deliberately narrowed to three methods over an allowlist (assertBridgedChannel, index.ts:161-164). The probe was written against the wide toolkit surface and never updated. Nothing failed at build time because the expression is a string evaluated in the renderer — there is no type checking across that boundary, which is also why a .d.ts that never had invoke did not catch it.

Consequences

• The three maintenance actions are unreachable. Anyone using the probe to drive a scan gets window.electron.ipcRenderer.invoke is unavailable, which reads like an environment problem rather than a surface mismatch.
• This is on the path [release/database] Prove default-on search-index split in an isolated CoreApp profile #1748 needs: triggering a file-provider scan against a disposable profile is exactly what --runMaintenanceAction scan is for.
• assertBridgedChannel means even a send-based rewrite needs app:indexed-source:scan on BRIDGED_IPC_CHANNELS, and a send has no reply — so the probe would also need a matching on for the result. It is not a one-word substitution.

Suggested direction

Either re-expose a narrow invoke restricted to the same allowlist (keeps the request/response shape the probes want), or convert the three actions to send + on and add the channels to the allowlist. The first is smaller; the second keeps the preload's current no-invoke posture.

Whichever way, the probe's inline expression should be typed against BridgedElectronAPI rather than written free-hand, or the next narrowing breaks it the same silent way.

Verification

macOS, dev build launched from the repo root with an isolated userDataDir, CDP attached on 9333, bridge read with Runtime.evaluate. The .d.ts and preload source quoted above are from origin/master.

[TalexDreamSoul]

Better suggested direction than the two I offered, found by looking at how the app itself does it.

The scan is already reachable from the renderer — just not the way the probe reaches for it. The Settings UI triggers it through the typed SDK:

SettingFileIndex.vue:454   const result = await settingsSdk.indexedSource.scan({ … })
settings.ts:209            scan: (request) => transport.send(AppEvents.indexedSource.scan, request)

That goes over TuffTransport, not over ipcRenderer.invoke, and it works today because the UI does it. So nothing is missing from the app — the probe is the only thing calling a method the preload never exposed.

That changes the fix. Re-adding invoke to the preload, which was my first suggestion, would reopen the surface the preload's own comment says was deliberately closed:

invoke and sendSync are deliberately absent rather than allowlisted — nothing calls them, and adding them back should be a decision…

It would also be adding a second way to do something the app already has one way to do.

Driving the button is the option that matches both the preload's posture and the probe's own conventions. coreapp-packaged-indexing-diagnostics-probe.ts already contains clickSourceDetailExpression, which finds a control by its visible text and clicks it — the same technique, one control further. I used exactly that shape in #1774 to open a dialog and route a window, and it works over CDP with no preload changes.

The trade is that a text-matched button is more brittle than an API call, and it needs the window to be on the right settings route first. Both are already solved in that file.

One thing that does not change either way: the expression is a string evaluated in the renderer, so nothing type-checks it against BridgedElectronAPI. Whatever replaces invoke here will drift the same silent way the next time the surface moves, unless the probe asserts the shape it depends on before using it — a cheap if (!window.electron?.ipcRenderer?.on) throw at the top is not enough, because that is exactly what it already does and it still shipped broken for however long.

[TalexDreamSoul]

Correcting the scope of my own report: this is not about --runMaintenanceAction, and it is not one script.

I filed this as "the maintenance action always throws". Reading the file to fix it, two things were larger than that.

1. The main path was broken too, behind no flag. loadDiagnosticsExpression — called unconditionally at line 1268 — also used invoke. And the target selector required a capability that can never be true:

export function selectSettingsTarget(...) {
  return snapshots.find((entry) =>
    entry.target.type === 'page' && … && entry.snapshot.hasIpcInvoke && …

with hasIpcInvoke: Boolean(window.electron?.ipcRenderer?.invoke). Always false, so the selector matched no target at all. The probe could not choose a window, let alone run an action. Its unit test passed because the fixtures said hasIpcInvoke: true — a value no renderer produces, so the test described a window that does not exist.

2. Four of the nine CDP probes have the same dependency, measured with the set of CDP users as the denominator so the count is not a guess:

probe	ipcRenderer.invoke references
coreapp-visible-app-index-workbench-probe.ts	7, incl. the same hasIpcInvoke selector at 1027 / 1037 / 1066
coreapp-packaged-indexing-diagnostics-probe.ts	4
coreapp-visible-assistant-floating-ball-probe.ts	1
coreapp-visible-assistant-image-translate-probe.ts	1

So this is systemic. It most likely dates to whenever the preload was narrowed — the four were written against a surface that once had invoke, and nothing failed loudly because a probe that throws on launch looks like a probe nobody ran.

PR #1781 fixes the one this issue names, rebuilt on send + on against the renderer's own envelope. The other three are untouched on purpose: bundling them is one unreviewable diff across four tools I cannot execute here, and the fix is not literally copy-paste — the assistant probes call different events.

This issue should stay open for those three, or be closed in favour of a new one scoped to them; I have left it open rather than choosing for you.

Also worth correcting: my earlier suggestion in this thread to drive the UI button instead. That was aimed at the maintenance action, and it does not solve the diagnostics read, which needs structured data back rather than a click. The send + on reconstruction covers both, and does not widen the preload surface either.