bug: Sentry debug ID injection causes OOM during module loading

[isshaddad]

Provide environment information

n/a

Describe the bug

Sentry's debug ID injection (sentry-cli sourcemaps inject) adds new Error().stack calls to every bundled .mjs file.

Trigger.dev's source-map-support library parses sourcemaps on every .stack access. This causes all sourcemaps to be parsed during module loading, leading to OOM before any task code runs.

Affects large projects (e.g., ~2000+ bundled files) on smaller machines like small-1x.

Reproduction repo

n/a

To reproduce

1. Deploy a project with many bundled files to Trigger.dev
2. Enable Sentry debug ID injection: sentry-cli sourcemaps inject --ext mjs
3. Use small-1x machine (0.5GB RAM)
4. Trigger any task
5. Task fails with OOM before execution

Workaround: Skip sourcemaps inject step, rely on release-based sourcemap matching.

Additional information

Potential fixes:

• Lazy sourcemap parsing (only on actual errors)
• Config option to disable source-map-support
• Document limitation for Sentry users

[ericallam]

@claude

[claude]

Claude finished @ericallam's task in 3m 17s —— View job

---

Analysis Complete

• Understand the issue and codebase context
• Locate relevant source-map-support code
• Analyze the root cause
• Propose solution approach

---

Root Cause Analysis

The issue is a specific interaction between Sentry's debug ID injection and source-map-support:

1. Sentry's sourcemaps inject adds new Error().stack calls to every bundled .mjs file for debug ID mapping
2. source-map-support hooks Error.prepareStackTrace - meaning every .stack access triggers sourcemap parsing
3. During module loading, Sentry's injected code executes new Error().stack
4. This causes all sourcemaps to be parsed synchronously during the import phase - before any task code runs
5. For large projects (~2000+ files), this creates a massive memory spike that exceeds small-1x (0.5GB RAM)

Key insight: While source-map-support is designed to be lazy (only parsing on actual errors), Sentry's injection turns every module import into an "error stack access" event.

---

Proposed Solutions

Option 1: Add config option to disable source-map-support (Recommended)

Add a new runtime.sourceMapSupport config option to TriggerConfig:

// In packages/core/src/v3/config.ts
export type TriggerConfig = {
  // ...
  runtime?: {
    /**
     * Enable source-map-support for better stack traces.
     * Set to false if using tools that access Error.stack during module loading
     * (e.g., Sentry debug ID injection), which can cause OOM on memory-constrained machines.
     * 
     * @default true
     */
    sourceMapSupport?: boolean;
  };
};

Then conditionally install in worker entry points:

// In entryPoints/*-worker.ts
if (config?.runtime?.sourceMapSupport !== false) {
  sourceMapSupport.install({
    handleUncaughtExceptions: false,
    environment: "node",
    hookRequire: false,
  });
}

Pros: Simple, user-controlled, no performance impact
Cons: Users lose source-mapped stack traces

Option 2: Lazy/deferred sourcemap parsing

Use a custom retrieveSourceMap callback that defers parsing until an actual error handler requests it:

sourceMapSupport.install({
  handleUncaughtExceptions: false,
  environment: "node",
  hookRequire: false,
  retrieveSourceMap: (source) => {
    // Only parse sourcemaps when explicitly needed (e.g., uncaught exception handlers)
    if (!shouldParseSourceMaps()) {
      return null;
    }
    // Default behavior
    return undefined;
  },
});

Pros: Preserves stack traces for real errors, prevents OOM during loading
Cons: More complex, needs careful implementation to track "real" vs "synthetic" stack access

Option 3: Environment variable toggle (Quick fix)

Add TRIGGER_DISABLE_SOURCE_MAP_SUPPORT=1 env var check:

if (process.env.TRIGGER_DISABLE_SOURCE_MAP_SUPPORT !== "1") {
  sourceMapSupport.install({ ... });
}

Pros: Immediate fix, no config schema changes
Cons: Less discoverable, not as clean

---

Recommendation

I'd suggest implementing Option 1 (config option) as the primary solution, with Option 3 (env var) as a quick workaround users can use immediately.

Would you like me to implement one of these solutions?

[ericallam]

@claude could you investigate option 2 first and event see if thats possible?

[claude]

Claude finished @ericallam's task in 5m 46s —— View job

---

Investigation Complete: Lazy Sourcemap Parsing (Option 2)

• Understand how source-map-support works and its API
• Analyze current implementation in Trigger.dev worker entry points
• Research if lazy/deferred parsing is feasible
• Determine implementation approach
• Report findings

---

Summary

Yes, Option 2 (lazy/deferred sourcemap parsing) is feasible.

The most practical approach is Phase-Based Deferred Parsing: skip sourcemap parsing during module loading, enable it once bootstrap completes.

How it works:

let loadingPhase = true;

sourceMapSupport.install({
  handleUncaughtExceptions: false,
  environment: "node",
  hookRequire: false,
  retrieveSourceMap: (source) => {
    // Skip parsing during module loading phase
    if (loadingPhase) return null;
    // Return undefined to use default behavior
    return undefined;
  },
});

// ... later, after bootstrap() completes:
loadingPhase = false;

Why this works:

• During loading: Sentry's new Error().stack calls return unmapped stacks (fast, no memory pressure)
• During runtime: Task execution errors get full sourcemap support
• Trade-off: Import errors won't have mapped stacks, but they already have good bundler messages

Why V8 can't distinguish "synthetic" vs "real" errors:

• Error.prepareStackTrace is called identically for both
• No metadata about whether error was thrown or just had .stack accessed
• No API to detect module loading context

Files to modify:

• packages/cli-v3/src/entryPoints/managed-run-worker.ts
• packages/cli-v3/src/entryPoints/dev-run-worker.ts
• packages/cli-v3/src/entryPoints/managed-index-worker.ts
• packages/cli-v3/src/entryPoints/dev-index-worker.ts

Let me know if you'd like me to implement this!

---

[ericallam]

@claude implement this and please create a reference project as well to test this

[claude]

Claude finished @ericallam's task in 6m 31s —— View job • claude/issue-2920-20260121-0712 • Create PR ➔

---

Implementation Complete

• Read current worker entry point implementations
• Implement phase-based deferred sourcemap parsing in all worker entry points
• Create reference project to test OOM fix with Sentry-like debug ID injection
• Add changeset for the fix
• Commit and push changes

---

Summary

Implemented phase-based deferred sourcemap parsing to fix OOM during module loading when using Sentry's debug ID injection.

Changes:

1. New utility module (packages/cli-v3/src/entryPoints/deferredSourceMapSupport.ts):

   • installDeferredSourceMapSupport() - Installs source-map-support with a custom retrieveSourceMap callback that returns null during loading phase
   • enableSourceMapSupport() - Enables sourcemap parsing after bootstrap completes

2. Updated worker entry points:

   • managed-run-worker.ts - Uses deferred sourcemap support, enables after bootstrap
   • dev-run-worker.ts - Uses deferred sourcemap support, enables after bootstrap
   • managed-index-worker.ts - Uses deferred sourcemap support, enables after bootstrap
   • dev-index-worker.ts - Uses deferred sourcemap support, enables after bootstrap

3. New reference project (references/sentry-sourcemap-oom/):

   • Contains 10 simulated modules that mimic Sentry's debug ID injection pattern
   • Each module has new Error().stack called during import (like Sentry does)
   • Can be used to test the fix works correctly

How it works:

• During module loading phase, retrieveSourceMap returns null, skipping all sourcemap parsing
• After bootstrap completes, the loading phase flag is set to false, enabling normal sourcemap retrieval
• Runtime errors during task execution get full sourcemap support as before

Trade-off: Import errors won't have source-mapped stack traces, but bundler messages are usually sufficient for those cases.

--- |