Prime Agent 0.7.2: isolated RLM worker reaches the normal V8 heap limit and aborts on Linux/WSL2

[Bruce-anle]

Summary

I am reporting one observed worker-crash event for correlation and maintainer guidance. This is an incident/triage report, not a root-cause claim, a duplicate claim, or a repair proposal.

Environment

• Prime Agent 0.7.2
• Node.js v24.14.0
• Linux/WSL2
• One isolated RLM worker
• One observed production/local deployment event; this is not a deterministic reproduction

Observed sequence

At approximately 2026-08-16 06:39:37Z, the isolated worker's stderr showed two major V8 GC cycles. After the second cycle, approximately 4068.6 MB remained live in a 4131.2 MB heap space. The worker then reported:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

The worker aborted with SIGABRT / signal 6. Later, at approximately 06:40:22Z, the supervisor reported two ECONNRESET reads; recovery followed shortly afterward. The reset and recovery are downstream consequences in this observed sequence, not evidence that they caused the V8 failure.

Heap-limit and termination-boundary evidence

An independent probe using the same installed Node/V8 binary reported a default V8 heap_size_limit of approximately 4,496,293,888 bytes. No custom reduced heap flag was observed for the installed launch path. The crashed process's complete historical argv was not recovered, so this should not be read as a complete reconstruction of its original launch arguments.

Preserved incident-window journal and cgroup evidence contained no kernel OOM, cgroup OOM-kill, or systemd-oomd kill signal. This strongly weighs against an external kernel/cgroup/oomd kill as the observed termination mechanism. The negative evidence is limited to the preserved incident window and sampled cgroups; it is not a claim that such signals are universally absent.

Impact

The isolated worker crashed, interrupting the supervisor connection and requiring worker recovery. This report does not establish data loss or a broad client-availability impact.

Related public records

These are related records for correlation only. None is presented as an exact match, proof of duplicate behavior, or confirmation of this event's root cause.

• #1288 - reporter-reported v0.7.2 / Node 24.13 Linux/RLM-worker V8 heap fatal followed by ECONNRESET and recovery; currently closed as not planned. The closure and response do not confirm a root cause.
• #1063 - reporter-reported long autonomous-goal V8 OOM without RLM children; currently closed as not planned. The author's proposed mechanism was not maintainer-confirmed.
• #1054 - reporter-reported tool-heavy RLM / child_usage_attributed growth with high worker memory; currently closed as not planned. It does not provide maintainer confirmation that its attribution path caused this event.
• #1440 - related open Discussion with 0 comments that links historical reports; it contains no new OOM evidence or maintainer technical confirmation for this event.

There is no exact matching Discussion identified here, and there is no maintainer root-cause confirmation for this event.

The following merged PRs are mentioned only as distinct historical mitigations in adjacent areas, not as a fix for this active-worker OOM:

• #212 - saved-session listing memory
• #549 - large session-load memory
• #583 - lazy child-session hydration
• #589 - intra-tree child-session passivation
• #547 - cleanup of deleted subagent runtimes during compaction
• #1450 - removal of deleted RLM-child kernel state and artifact-path deduplication

Their adjacent scope does not establish that this event is the same failure mode or that any of them fixed it.

What remains unknown

• Which allocation or retained-object class owned the live heap.
• Whether attribution came from a large legitimate session/tool payload, another object graph, or some combination.
• The exact operation boundary at which the heap crossed the limit.
• Recurrence frequency under comparable workloads.
• Whether the event can be reproduced deterministically.
• Whether the relevant classification is a product bug, workload characteristic, integration behavior, or a combination.

No heap snapshot, allocation profile, turn-by-turn heap series, or retained-object graph is available from this event, so I am not assigning any of those explanations as the cause.

Questions for maintainers

1. Is the child_usage_attributed attribution path discussed around #1288 or #1054 known to be related to this kind of worker-local V8 limit event?
2. What bounded behavior should be expected for per-message child_usage_attributed under a long-lived or tool-heavy session?
3. Is there a recommended low-cost telemetry configuration, or an existing regression test, that would distinguish retained session/tool data from another allocation path without exposing prompt or tool contents?
4. What sanitized artifact would be most useful for triage (for example, versions, worker launch metadata, bounded V8 heap statistics, cgroup event counters, and an operation category without session contents)?

Scope of this report

This Discussion is intended to correlate the observed signal with existing reports and obtain maintainer direction. I am not opening a PR, submitting a patch, or requesting a specific unverified fix.

[sankks11]

Independent daemon-log evidence confirms repeated worker V8 heap aborts, while remaining neutral on the retained-object cause.

One isolated session worker hit four heap OOM aborts on 2026-08-15:

• 08:47:27Z: Ineffective mark-compacts near heap limit
• 17:54:12Z: the same fatal error
• 19:32:32Z: the same fatal error
• 22:29:49Z: Reached heap limit

The associated journal had grown to roughly 24.6 MB, 28.5 MB, 29.3 MB, and 32.8 MB at those recovery boundaries. Each abort was followed by worker recovery that warned an in-flight rlm_child_update operation might have an uncertain outcome.

This proves recurrence and recovery impact, but not which objects retained the heap. I do not have a heap snapshot, so I would not attribute these four aborts to one mechanism yet. Large RLM metadata streams were present and may be an amplifier.