JavaScript OOM

[smter]

dsh web
dsh web: http://127.0.0.1:3080
(node:20440) ExperimentalWarning: stripTypeScriptTypes is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

<--- Last few GCs --->

[20440:00000215F4E8D000]   134452 ms: Mark-Compact 4044.5 (4129.8) -> 4029.1 (4130.0) MB, pooled: 0 MB, 616.26 / 0.00 ms  (average mu = 0.077, current mu = 0.015) allocation failure; scavenge might not succeed
[20440:00000215F4E8D000]   135079 ms: Mark-Compact 4044.8 (4130.0) -> 4029.5 (4130.5) MB, pooled: 0 MB, 617.49 / 0.00 ms  (average mu = 0.047, current mu = 0.016) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF76F704BB7 node::SetCppgcReference+21127
 2: 00007FF76F664C6B EVP_MD_meth_get_input_blocksize+102619
 3: 00007FF770272A11 v8::Isolate::ReportExternalAllocationLimitReached+65
 4: 00007FF77025F4C6 v8::Function::Experimental_IsNopFunction+3318
 5: 00007FF7700BBB10 v8::internal::StrongRootAllocatorBase::StrongRootAllocatorBase+33904
 6: 00007FF7700B4F5A v8::internal::StrongRootAllocatorBase::StrongRootAllocatorBase+6330
 7: 00007FF7700B0775 v8::CpuProfileNode::GetScriptResourceNameStr+190293
 8: 00007FF76FA37AAD BIO_ssl_shutdown+189

差不多是使用goal进行翻译工作时，建立了480个子代理的时候遇到的

[denial123789]

This is consistent with a workflow-capacity failure, but the current evidence does not yet distinguish a leak from legitimate retained state.

Two source-backed details matter here:

• maxConcurrentAgents defaults to 0, which auto-resolves to min(16, max(1, cores - 2)).
• maxTotalAgents defaults to 1000. That is a runaway-call guard, not a memory budget, so a fatal OOM after about 480 children can occur below it.

For a translation workload of this size, I would split the input into restartable batches, begin with 2-4 concurrent children, set maxTotalAgents close to the expected batch size, and persist results between batches. Record peak heap, total and settled child counts, duration, failures, and retries. If heap continues rising after children settle, stop the run and preserve a heap profile before increasing either limit. Raising --max-old-space-size alone only moves the failure boundary.

Example starting bounds:

- id: delegation
  name: cordis:group
  group: true
  isolate:
    workflows: true
  config:
    - id: workflow-worker-thread
      name: '@deepseek-ai/dsh-workflow-worker-thread'
      config:
        provider: spawn
        maxConcurrentAgents: 4
        maxTotalAgents: 64
    - id: tool-workflow
      name: '@deepseek-ai/dsh-tool-workflow'

Visual operator guide with the evidence boundary and batching route: https://sandbaseai.github.io/deepseek-harness-handbook/subagent-scale-oom.html

Handbook source update for review: sandbaseai/deepseek-harness-handbook#19

[yha9806]

Reproduced as persistence backpressure, not a count-only leak.

• Controls: 480 tiny-output children completed under a 384 MiB old-space cap. At 480 × 96 KiB CJK results, stock JSONL reliably OOMed in ValueDeserializer::ReadTwoByteString / worker::StructuredClone; the same load without persistence completed.
• Cause: SessionWriteBehind.enqueue() clones event data, while a completed local child can release its workflow slot before that session reaches durability. Execution stays capped at 16, but hundreds of result-sized copied event graphs can accumulate.
• Fix: after run.result settles, await that local session flush() before forwarding ChildSettled. The workflow slot now owns persistence lifetime; remote providers are unchanged, and flush failures remain infrastructure failures.
• Result: the same 480 × 96 KiB run completed with ~101 MiB peak heap, persistence peak 16, and zero retirement backlog. Candidate 2774160; 107 package tests, built-worker E2E, and typecheck passed.
• Trade-off and scope: local result latency now includes durability. This was a synthetic macOS arm64 / Node 25.9 reproduction; Windows and the supported Node matrix remain to be checked.

[anshuman2502]

This is a this has occurred because "JavaScript heap memory was filled" error.
The error occurs because Node.js has hit its default memory limit (around 4GB on 64-bit systems). so we need to increase the heap size when running your dsh web command.

Quick Fix
set NODE_OPTIONS=--max-old-space-size=4096 / "8192 - 8gb"
dsh web

Anyways, with the current evidence it's hard to determine the root cause. If this keeps happening even with increased memory, there might be a memory leak worth investigating.

Context: This appears to be a separate issue from the persistence backpressure problem described above—this is a general heap OOM on the dsh web server, not the workflow worker. The --max-old-space-size fix should resolve it for now, but if you're seeing repeated OOMs under normal load, profiling with --inspect or heap snapshots would help identify any leaks.

[tkornblit]

We found that the fix for this is here: https://tomkornblit.substack.com/p/we-gave-an-agent-write-access-to