denoland/deno · critical

Failed to initialize JsRuntime for snapshotting: {:?}

Error message

Failed to initialize JsRuntime for snapshotting: {:?}

What it means

JsRuntimeForSnapshot::new is the panicking constructor used when generating snapshots (the create_snapshot / build.rs path): like JsRuntime::new it delegates to try_new and panics with the debug-formatted error if runtime construction for snapshotting fails. Because this variant deserializes an existing startup_snapshot and prepares the isolate for a new snapshot, typical failures are an incompatible base snapshot or extension init errors. The try_new twin returns Result instead of panicking.

Source

Thrown at libs/core/runtime/jsruntime.rs:2879

    )
  };

  let scope = &mut v8::ContextScope::new(scope, context);

  let global = context.global(scope);
  for middleware in global_object_middlewares {
    middleware(scope, global);
  }
  context
}

impl JsRuntimeForSnapshot {
  /// Create a new runtime, panicking if the process fails.
  pub fn new(options: RuntimeOptions) -> JsRuntimeForSnapshot {
    match Self::try_new(options) {
      Ok(runtime) => runtime,
      Err(err) => {
        panic!("Failed to initialize JsRuntime for snapshotting: {:?}", err);
      }
    }
  }

  /// Try to create a new runtime, returning an error if the process fails.
  pub fn try_new(
    mut options: RuntimeOptions,
  ) -> Result<JsRuntimeForSnapshot, CoreError> {
    setup::init_v8(
      options.v8_platform.take(),
      true,
      options.unsafe_expose_natives_and_gc(),
    );

    let runtime = JsRuntime::new_inner(options, true)?;
    Ok(JsRuntimeForSnapshot(runtime))
  }

View on GitHub (pinned to 336da420f4)

Solutions

1. Use JsRuntimeForSnapshot::try_new in custom snapshot tooling to surface the CoreError instead of a panic
2. Regenerate the base startup snapshot with the current deno_core before building the derived snapshot
3. Ensure build.rs prints rerun-if-changed lines (create_snapshot returns them) so cargo rebuilds the snapshot when inputs change
4. Keep the extension vector identical between base snapshot creation and the snapshotting runtime

Example fix

// before
let rt = JsRuntimeForSnapshot::new(options); // panics inside build.rs

// after
let rt = JsRuntimeForSnapshot::try_new(options)
  .expect("snapshot runtime init"); // or propagate the CoreError

// In build.rs-adjacent tooling: sanity-check the base snapshot boots for-snapshot
// before the real run.
if JsRuntimeForSnapshot::try_new(base_options).is_err() {
  panic!("base startup snapshot is incompatible; regenerate it first");
}

let rt = match JsRuntimeForSnapshot::try_new(options) {
  Ok(rt) => rt,
  Err(err) => {
    eprintln!("snapshot runtime init failed: {err:?}");
    std::process::exit(1);
  }
};

When it happens

Trigger: Running create_snapshot (usually from build.rs) with a startup_snapshot base built by a different deno_core version; snapshot-generation extension list differing from the base snapshot's layout; extension init JS throwing during the snapshot build; CI environments where the snapshot artifact is stale relative to the source tree.

Common situations: cargo build picking up a cached/stale snapshot file after a deno_core bump; build.rs not emitting cargo:rerun-if-changed for extension changes, so the snapshot-for-snapshotting runtime is built against an outdated base.

Related errors

• {path} exists
• unable to convert
• Failed to initialize a JsRuntime: {}
• Attempted to read snapshot data out of range: {id} (of {})
• Attempted to read the snapshot data at index {id} twice

AI-assisted analysis of denoland/deno@336da420f4 (2026-08-20). Data as JSON: /api/errors/5eed52d794054167. Report an issue: GitHub.