Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

permissions: { network: "allow" } authorizes egress but guest fetch() hangs — no host network adapter on public API

Aperta
  • Qualcosa non va?
#96 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
node.js, typescript
Ambito
api, backend, documentation

Direzione di ricerca

Inizia riproducendo il timeout di 10 secondi con l’API pubblica NodeRuntime.create, quindi esamina NodeRuntimeCreateOptions e le definizioni di test-runtime referenziate, inclusi NetworkAdapter e hasHostNetworkAdapter(). Controlla l’index.d.ts pubblico di @secure-exec/core e la sezione Permissions Configuration della guida rapida. Il lavoro è completato quando le richieste in uscita funzionano tramite una configurazione pubblica documentata oppure network: "allow" fallisce rapidamente senza un adapter, e la guida rapida è stata chiarita.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Granting permissions: { network: "allow" } via the public NodeRuntime.create API authorizes guest network access, but there is no way through the public SDK to provide a host network adapter to actually service outbound requests. As a result, an outbound fetch() in guest code hangs indefinitely instead of either succeeding or failing fast.

The quickstart's Permissions Configuration section implies network: "allow" is sufficient to enable network, so this is misleading as written.

Environment

Repro

import { NodeRuntime } from "secure-exec";

const rt = await NodeRuntime.create({ permissions: { network: "allow" } });
const r = await Promise.race([
  rt.run(`
    try { const res = await fetch("https://example.com"); __return({ status: res.status }); }
    catch (e) { __return({ err: String(e.message || e) }); }
  `),
  new Promise((res) => setTimeout(() => res({ value: { TIMEOUT_10s: true } }), 10000)),
]);
console.log("result:", r.value); // -> { TIMEOUT_10s: true }  (hangs until the race timer fires)
await rt.dispose();

Observed: the guest fetch never resolves — bounded to a 10s race, it times out at exactly 10s every time.

Control checks:

  • A host-side fetch("https://example.com") returns 200 in the same environment, so host egress is not the problem.
  • The default deny path works correctly and fails fast: without the permission, the guest fetch rejects promptly with fetch failed.

So the issue is specific to the network: "allow" + outbound-request path hanging rather than completing.

Root cause (from reading the type defs)

Granting the permission only authorizes network; performing it requires a host network adapter. The architecture clearly expects one — @secure-exec/core's test-runtime defines createNodeHostNetworkAdapter(), createDefaultNetworkAdapter(), a NetworkAdapter interface, and hasHostNetworkAdapter().

However:

  • test-runtime is not re-exported from @secure-exec/core's index.d.ts, and the public secure-exec package only re-exports NodeRuntime + types.
  • NodeRuntimeCreateOptions has no field to supply a network adapter (only permissions, env, cwd, commandsDir, files, mounts, nodeModules, tools, loopbackExemptPorts).

So through the public API there is no way to wire egress, and network: "allow" ends up granting permission with no transport behind it.

Suggested fix (either)

  1. Expose a host network adapter on NodeRuntimeCreateOptions (e.g. network / networkAdapter), and document it in the quickstart, or
  2. Make network: "allow" with no available adapter reject fast with a clear error (e.g. "network permitted but no host network adapter configured") instead of hanging.

Either way, the quickstart's Permissions section should clarify whether outbound HTTP is supported on the public SDK in 0.3.0 and, if so, the complete setup required.

Minor doc nit

The quickstart code uses .run<{...}>(...) (TS generics) and the package is "type": "module", but doesn't mention that a .js file in a CommonJS project won't load it — it needs .mjs or "type": "module". Worth a one-line note for JS users following along.

Lingua principale
TypeScript
Stelle
1k
Fork
54
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rivet-dev/dynamic-apps

Tutte le issue di rivet-dev/dynamic-apps

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.