rivet-dev / rivet-dev/dynamic-apps
createResidentRunner().exec() always fails: "Cannot resolve module 'data:text/javascript;base64,...'"
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-execversions tested:0.3.3(latest) and0.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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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