Skip to main content
← Back to list
01Issue
BugShippedSwamp CLI
Assigneesstack72

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

  1. Have a repo with ~2300 models and substantial data (1.9GB data dir)
  2. Run: swamp serve --auth-mode token --admins 'user:webframp'
  3. 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.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

6/29/2026, 10:43:02 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack726/29/2026, 9:00:59 AM
Editable. Press Enter to edit.

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.

stack72 commented 6/29/2026, 10:43:11 AM

Thanks @webframp for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.