OpenClaw Test Heap Leaks

Classify the growth before choosing a fix.

• If growth is dominated by Vite/Vitest transformed source strings, Module, system / Context, bytecode, descriptor arrays, or property maps, treat it as likely retained module graph growth in long-lived workers.
• If growth is dominated by app objects, caches, buffers, server handles, timers, mock state, sqlite state, or similar runtime objects, treat it as a likely cleanup or lifecycle leak.
• If the names are ambiguous, stop short of a confident label and inspect retainers/dominators in DevTools for the top deltas.

Fix the right layer.

• For likely retained transformed-module growth in shared workers:
• Prefer timing and hotspot-driven scheduling fixes first. Check whether the file is already represented in test/fixtures/test-timings.unit.json and whether scripts/test-update-memory-hotspots.mjs should refresh the measured hotspot manifest before hand-editing behavior overrides.
• Move hotspot files out of the real shared lane by updating test/fixtures/test-parallel.behavior.json only when timing-driven peeling is insufficient.
• Prefer singletonIsolated for files that are safe alone but inflate shared worker heaps.
• If the file should already have been peeled out by timings but is absent from test/fixtures/test-timings.unit.json, call that out explicitly. Missing timings are a scheduling blind spot.
• For real leaks:
• Patch the implicated test or runtime cleanup path.
• Look for missing afterEach/afterAll, module-reset gaps, retained global state, unreleased DB handles, or listeners/timers that survive the file.

Verify with the most direct proof.

• Re-run the targeted lane or file with heap snapshots enabled if the suite still finishes in reasonable time.
• If snapshot overhead pushes tests over Vitest timeouts, fall back to the same lane without snapshots and confirm the RSS trend or OOM is reduced.
• For wrapper-only changes, at minimum verify the expected lanes start and the snapshot files are written.