Error: Error invoking remote method 'workflow:watch-project': Error: No handler registered for 'workflow:watch-project' #26

Activity

1. sentry

   added

   bugSomething isn't workingSomething isn't working

   sentryAuto-created from Sentry crash reportAuto-created from Sentry crash report

   needs-triageAwaiting initial reviewAwaiting initial review

   on Aug 18, 2026
2. codedev-david commented on Aug 18, 2026

   

   codedev-david

   on Aug 18, 2026

   Owner

   More actions

   Auto-triage attempted but the candidate fix failed npx tsc. Human review needed. Log: C:\Users\DavidEngelhart\AppData\Local\termpolis\auto-triage\run-20260818-150422.log
3. codedev-david

   added

   auto-triage-attemptedAuto-triage script has tried to fix this issueAuto-triage script has tried to fix this issue

   on Aug 18, 2026
4. codedev-david

   added a commit that references this issue on Sep 13, 2026

   v1.41.3: an agent profile can no longer name a shell you do not have

   ...

   95ebb66
5. codedev-david commented on Sep 13, 2026

   

   codedev-david

   on Sep 13, 2026

   Owner

   More actions

   Fixed in v1.41.3 — same root cause as #25, same fix.

   workflow:watch-project has been registered since v1.31.0 (src/main/workflow/ipc.ts:154). The bug was a cold-boot ordering race: createWindow() (src/main/index.ts:2715) and registerWorkflowIpc(...) (src/main/index.ts:3554) sit ~840 lines apart inside the same app.whenReady().then(), so the renderer can reach ipcRenderer.invoke before the handler exists. That is also why the auto-triage bot's candidate fix failed npx tsc — it was trying to add a handler that was already there.

   This one had a worse consequence than #25. A lost workflow:list leaves an empty list, which is at least visible. A lost workflow:watch-project means the project's cron, git and file triggers never arm — silently, for the entire session. Workflows simply never fire, with nothing in the UI to say why.

   Fix (src/renderer/src/components/Sidebar/Sidebar.tsx): the project watcher is now re-armed on every retry attempt, not just the first — the lost call is precisely the one worth repeating — and its rejection is swallowed rather than escaping to Sentry. Retries happen only on rejection; an err() response is main answering and is treated as an answer.

   Tests — covered in tests/components/Sidebar.test.tsx, including a dedicated case asserting the watcher is re-armed on each attempt with the correct cwd and that its rejection never escapes.
6. codedev-david

   closed this as completedon Sep 13, 2026