You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@maka.apache.org by "me2seeks (via GitHub)" <gi...@apache.org> on 2026/08/22 03:35:36 UTC

[I] Desktop main process OOM after prolonged Runtime Host connection flapping (repeated MCP capability alignment failures) [maka]

me2seeks opened a new issue, #3458:
URL: https://github.com/apache/maka/issues/3458

### What happened

The Electron **main process** crashed with `JavaScript heap out of memory` after ~12 hours of uptime. The hours leading up to the crash are dominated by hundreds of repeated `[runtime-host] MCP capability alignment failed` errors.

Each of those log lines corresponds to exactly one `mcpCapabilityPublisher.bind()` call inside `registerHostClientIpc()` (`apps/desktop/src/main/runtime-host-boot.ts`), i.e. **one full Runtime Host candidate generation**. Hundreds of generations over ~12h means the host connection was flapping continuously:

- Every generation's `client.capability.replace` fails with `RuntimeHostRequestInterruptedError` (`dispatch: 'not_dispatched'`, `reason: 'connection_lost'`), caused by `RuntimeHostTransportError: read_eof` ("Runtime Host transport read side ended") or occasionally `read_timeout`.
- The desktop side respawns candidates via the reconnect lifecycle (backoff capped at 5s, no circuit breaker) and re-runs the full registration stack each time.

Per-generation cleanup *is* wired to candidate close (`disposeClientIpc` → unsubscribe + map deletion in `runtime-host-boot.ts`, `removeHandler` in `runtime-host-reconnecting-ipc-main.ts`, observer/provider teardown in `runtime-host-desktop-candidate.ts`). The OOM therefore indicates that some retention still accumulates across this churn. Pinning the exact retained root will need a heap snapshot under reproduction.

Expected behavior:
1. Long uptime with a flapping/unavailable Runtime Host must not exhaust the main-process heap.
2. A candidate that dies immediately after spawn should trigger backoff escalation / circuit-breaking instead of unbounded regeneration.

### How to reproduce

1. Run desktop from source on Windows: `npm run dev:hmr` in `apps/desktop`.
2. Leave it running for many hours while the Runtime Host connection keeps dropping (host transport read side ends repeatedly; root cause of the flapping itself is not yet identified).
3. Observe hundreds of `[runtime-host] MCP capability alignment failed` errors and steady main-process heap growth until V8 OOM.

### Environment

- Maka version or commit: workspace `@maka/desktop@0.1.11`, run from source (exact commit at crash time not captured)
- OS and version: Windows
- Surface: Desktop (Electron main process)
- Node.js version, if running from source: Electron-bundled Node (crash raised via `node_bindings.cc`)

### Logs, screenshots, or additional context

Crash:

```
[5420:...] 42867680 ms: Mark-Compact (reduce) 3612.6 (3948.2) -> 3612.6 (3887.0) MB ... last resort; GC in old space requested
[5420:...] ERROR:electron\shell\common\node_bindings.cc:189] OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
```

Representative repeating error (trimmed):

```
[runtime-host] MCP capability alignment failed: RuntimeHostRequestInterruptedError:
Runtime Host client.capability.replace was interrupted: the operation was not dispatched
operation: 'client.capability.replace', mode: 'command',
dispatch: 'not_dispatched', reason: 'connection_lost', retryable: false,
[cause]: RuntimeHostTransportError: Runtime Host transport read side ended
at #endRead (.../runtime-host/dist/transport/framed-transport.js:189:30)
code: 'read_eof'
```

Some late errors switch to `read_timeout`, consistent with the event loop degrading as the heap fills.

Areas worth instrumenting first during the fix:

- module-level maps in `runtime-host-boot.ts` keyed by target / `targetEpoch` across generations;
- the promise-chain queue in `runtime-host-capability-revision-publisher.ts`;
- per-generation session observation registry / native provider sets;
- reconnect lifecycle churn without escalation when a candidate dies at startup.

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org

Re: [I] Desktop main process OOM after prolonged Runtime Host connection flapping (repeated MCP capability alignment failures) [maka]

Posted by "me2seeks (via GitHub)" <gi...@apache.org>.

me2seeks commented on issue #3458:
URL: https://github.com/apache/maka/issues/3458#issuecomment-5422038486

   Reproduction evidence for prolonged flapping (parent tracking) — same Windows diagnostic as #3280 #issuecomment-5421983866.
   
   **Slice from 2026-08-26T07:10-07:11 (dev@32a1db0, win32):**
   - 8× `subscription.open` interrupted (`host.status` `read_timeout` → `connection_lost`) in ~90s at 07:10:07/07/24/30/43
   - 5× `client.capability.replace` `read_eof` (`transport read side ended`) at 07:11:03-07:11:55
   - Final `load-before: Desktop transcript generation changed` (observer.ts:1352)
   
   This matches #3280's `reads bound to dead connection` + #3795's `handler wait` window + #3847's 15s reconnectable-read budget exercised. No `runtime.sqlite` corruption; host was `reconnecting` (`Diagnostics unavailable`) with `<none>` process exits captured — flapping at transport level per this issue's `hundreds of MCP capability alignment failures` pattern.
   
   Full log and correlation already posted to #3280 #issuecomment-5421983866. Linking here so #3458's heap-verification gate has a concrete Windows reproduction without re-pasting the full dump.
   
   Relates to #3280, #3795, #3847.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org

Re: [I] Desktop main process OOM after prolonged Runtime Host connection flapping (repeated MCP capability alignment failures) [maka]

Posted by "M4n5ter (via GitHub)" <gi...@apache.org>.

M4n5ter closed issue #3458: Desktop main process OOM after prolonged Runtime Host connection flapping (repeated MCP capability alignment failures)
URL: https://github.com/apache/maka/issues/3458


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org

Re: [I] Desktop main process OOM after prolonged Runtime Host connection flapping (repeated MCP capability alignment failures) [maka]

Posted by "me2seeks (via GitHub)" <gi...@apache.org>.

me2seeks commented on issue #3458:
URL: https://github.com/apache/maka/issues/3458#issuecomment-5377691482

   Working on this — will follow up with a fix addressing the unbounded candidate regeneration during connection flapping and the cross-generation retention on the desktop side.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org