Relationships
#882 serve: V8 out-of-memory crash during catalog init on large repos (regression from #841)
Opened by webframp · 6/29/2026· Shipped 6/29/2026
Summary
swamp serve crashes with a fatal JavaScript out-of-memory error during catalog initialization on repos with ~2300 models and ~1.9GB of data. V8 heap grows to 4GB+ before crashing after ~9 minutes.
Environment
- swamp version:
20260628.043054.0-sha.84b695a8 - Repo: 2280 models, 45 workflows, 1.9GB data directory
- Platform: NixOS on WSL2
- Auth mode:
--auth-mode token
Reproduction
- Have a repo with ~2300 models and substantial data (1.9GB data dir)
- Run:
swamp serve --auth-mode token --admins 'user:webframp' - Observe ~7.5 min for catalog init (policy snapshot load), then V8 OOM crash at ~9 min
Expected Behavior
swamp serve should start within reasonable time/memory bounds regardless of repo size, or provide a mechanism to skip expensive catalog init (e.g. --skip-reports/--skip-checks flags).
Regression
This is a regression from startup bug #841:
sha.1d00e382(2026-06-25): ~68ms startup (confirmed working)sha.43cb5b74(2026-06-27): ~4min 47s startup (bug #841 filed)sha.84b695a8(2026-06-28): OOM crash at 4GB+ heap after ~9 min
Logs
04:06:42.363 serve Initializing repository
[~7.5 min gap]
04:14:15.176 swamp·domain·access·policy-snapshot Loaded policy snapshot: 1 active grant(s), 0 group(s)
04:14:15.178 serve Policy snapshot loaded (reload mode: "manual")
<--- GC logs --->
544696 ms: Scavenge 4090.9 -> 4089.5 MB
545209 ms: Incremental Mark-Compact 4093.2 -> 4089.1 MB
#
# Fatal JavaScript out of memory: Ineffective mark-compacts near heap limit
#
==== C stack trace ===============================
... (stack trace available)Workaround
Use the older sha.1d00e382 build which starts in ~68ms.
Shipped
Click a lifecycle step above to view its details.
webframp commented 6/29/2026, 4:57:13 AM
Follow-up: sha.1d00e382 also slow on large repos, just doesn't OOM
Tested sha.1d00e382 (previously reported as ~68ms startup) on the same repo (2280 models, 1.9GB data dir):
- Startup time: ~22 minutes for catalog init (not 68ms)
- Memory: RSS stable at ~500MB during init, grew to ~864MB during workflow execution
- Outcome: Succeeds — no OOM crash. All cron workflows fire correctly afterward.
- Contrast with sha.84b695a8: Same ~7-8 min init phase, but then V8 hits 4GB heap and OOMs
So the regression between sha.1d00e382 and sha.84b695a8 is specifically a memory regression (probably a leak or inefficient data structure during catalog init), not just a speed regression. Both builds are slow on large repos, but the newer one exhausts V8 heap.
The 68ms startup claim was likely on a fresh/minimal repo. On repos with real data volume, even the old build takes significant time to initialize the catalog.
Sign in to post a ripple.