rivet-dev / rivet-dev/dynamic-apps

createResidentRunner().exec() always fails: "Cannot resolve module 'data:text/javascript;base64,...'"

Open
#280 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
1k
Forks
51
Avg merge
6m
Merged PRs (30d)
13

Description

Summary

NodeRuntime.createResidentRunner() / NodeRuntimeResidentRunner.exec() (documented at https://secureexec.dev/docs/features/resident-runner) fails on every single call, regardless of the code snippet's content. Confirmed reproducible on both the latest (0.3.3) and rc (0.3.4-rc.1) npm dist-tags.

Environment

  • secure-exec versions tested: 0.3.3 (latest) and 0.3.4-rc.1 (rc)
  • Node.js: v24.18.0
  • OS: macOS, darwin-arm64 (@secure-exec/sidecar-darwin-arm64)

Repro

import { NodeRuntime } from "secure-exec";

const runtime = await NodeRuntime.create();
const runner = await runtime.createResidentRunner();

const result = await runner.exec(`console.log("hello");`);
console.log(result);

Expected

Per the docs: "A warm resident evaluation runs in roughly a millisecond" — the snippet should execute successfully (exitCode: 0, stdout containing hello).

Actual

Every call returns exitCode: 1 with the same class of error, e.g.:

{
  stdout: '',
  stderr: "Error: Cannot resolve module 'data:text/javascript;base64,Y29uc29sZS5sb2coImhlbGxvIik7#0' (imported from '/tmp/secure-exec-program-0.mjs'): not found. For a bare package, ensure it is installed in a node_modules directory on an ancestor of the importer (or bundle the entrypoint). If you mounted a host node_modules, point it at a directory that contains every symlink target (e.g. the workspace root): symlinks that escape the mount root are not followed.\n    at /tmp/secure-exec-program-0.mjs:238:65",
  exitCode: 1
}

This happens for:

  • The same snippet repeated 5x in a row
  • 5 distinct/unique snippets in a row
  • A trivial globalThis.counter++-style state test

i.e. it's not content-dependent — every single exec() call on a resident runner fails the same way.

Suspected root cause

The resident runner appears to work by running a small REPL-style loop inside the guest that evaluates each submitted snippet via a dynamic import() of a data:text/javascript;base64,... URL. The guest's module resolver doesn't seem to recognize the data: URL scheme as a special case — the error message ("ensure it is installed in a node_modules directory... ") reads like the resolver is falling through to its bare-specifier/node_modules lookup path instead of treating it as an inline module to evaluate directly. This would explain why the failure is 100% reproducible and independent of the snippet's content.

Given it reproduces identically on both 0.3.3 and 0.3.4-rc.1, this doesn't look like something recently fixed on the rc line.

Impact

This blocks the documented "trusted, repeated evaluation" use case (REPLs, eval loops, per-tenant persistent runtime reuse) that createResidentRunner() is specifically meant for — right now it's unusable for any real workload since 100% of calls fail.

Happy to provide more repro details/logs if useful.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the documented NodeRuntime.createResidentRunner() and NodeRuntimeResidentRunner.exec() flow, reproducing the failure with the supplied snippet on the affected package versions. Inspect how the resident runner resolves the submitted data:text/javascript module; done means repeated exec() calls return exitCode 0 and stdout contains the snippet output without the resolver error.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, typescript
Domain
backend, security
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.