Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#280 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
node.js, typescript
Área
backend, security

Línea de trabajo

Comienza con el flujo documentado de NodeRuntime.createResidentRunner() y NodeRuntimeResidentRunner.exec(), reproduciendo el fallo con el snippet proporcionado en las versiones afectadas del paquete. Inspecciona cómo el resident runner resuelve el módulo data:text/javascript enviado; se considera terminado cuando las llamadas repetidas a exec() devuelven exitCode 0 y stdout contiene la salida del snippet sin el error del resolver.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
1k
Forks
54
Sin PR fusionados en 30 d

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rivet-dev/dynamic-apps

Todos los issues de rivet-dev/dynamic-apps

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.