Python launched through guest shell stalls on queued filesystem RPCs

Fermée
  • Quelque chose ne va pas ?
#2,012 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@ankssjain y travaille déjà.

Depuis le 29/9/2026.

  • #2013 par @ankssjain — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
52/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
node.js, rust, wasm
Domaine
backend, operating-systems

Piste de recherche

Start at pump_child_process_events_nowait and the WASM parent polling path, then run repro.mjs in both direct and shell modes. Trace how queued Python VFS requests and socket completions are assigned beneath WASM parents while stdout, stderr, and exit remain on the parent path. Done means the shell invocation completes with exit code 0 and stdout 42\n without regressing direct execution.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Running python -c "print(42)" through the guest shell times out, while starting Python directly succeeds. This reproduces with embedded AgentOs.create(); no actor, Rivet Engine, database, or LLM is involved.

Reproduction

Tested with Node.js 24 on Linux arm64 and the published packages:

npm install --save-exact @rivet-dev/[email protected] @rivet-dev/[email protected]
node repro.mjs direct
node repro.mjs shell

repro.mjs:

import { AgentOs } from "@rivet-dev/agentos-core";
import { SidecarProcess } from "@rivet-dev/agentos-runtime-core";

// Isolate this timeout from a separate command-registration problem:
// configureVm currently omits the runtime commands registered by createVm.
const configureVm = SidecarProcess.prototype.configureVm;
SidecarProcess.prototype.configureVm = function (session, vm, options) {
  return configureVm.call(this, session, vm, {
    ...options,
    bootstrapCommands: [
      ...new Set(["node", "npm", "npx", "python", "python3",
        ...(options.bootstrapCommands ?? [])]),
    ],
  });
};

const vm = await AgentOs.create({
  defaultSoftware: true,
  permissions: {
    fs: "allow", process: "allow", childProcess: "allow",
    network: "deny", env: "deny",
  },
});
try {
  const options = { timeoutMs: 10_000, output: { capture: "all" } };
  const result = process.argv[2] === "direct"
    ? await vm.process.execFile("python", ["-c", "print(42)"], options)
    : await vm.process.exec('python -c "print(42)"', options);
  console.log(result);
} finally {
  await vm.dispose();
}

Expected: both invocations finish with exit code 0 and stdout 42\n.

Observed:

  • Direct: outcome: "succeeded", exitCode: 0, stdout: "42\n" (about 2.4 seconds).
  • Shell: outcome: "timed_out", exitCode: 137, empty stdout/stderr after 10 seconds, error code execution_timed_out.
Diagnosis

The shell resolves and starts Python. Python then stalls during filesystem initialization, before reaching the user code. Its initial fsReaddir("/") needs a Python VFS RPC response.

In current main (63ae3b256749d47c7b3a7c463128d5deda57d1bb):

  1. The WASM parent's polling path requeues Python VFS events for the owned process-event supervisor and wakes it.
  2. pump_child_process_events_nowait skips all children whose parent is WASM, to preserve the parent's ownership of stdout/stderr/exit.
  3. That skip also prevents the supervisor from claiming the queued Python request. Python waits for the response while the shell waits for Python.

The repair should service supervisor-owned Python VFS requests (and Python socket completions) beneath WASM parents while keeping stdout/stderr/exit on the parent's polling path.

Related: #2007 addresses queued JavaScript process-control requests beneath WASM parents. Python VFS requests are a separate event variant and need handling too. This also differs from #1881 / #1980: in this reproduction Python is found and starts, then stalls.

Langage dominant
Rust
Étoiles
4.8k
Forks
270
Merge moyen
13 h 37 min
PR mergées (30 j)
48

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de rivet-dev/agentos

Toutes les issues de rivet-dev/agentos

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.