Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Native root filesystem returns stale data after a guest process overwrites an API-created file

クローズ
  • 何か問題がありますか？
#1,901 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@eersnington がすでに取り組んでいます。

2026年10月21日 から。

  • #2070 @eersnington による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
rust, sqlite, typescript
領域
databases, operating-systems

調査の方向性

crates/native-sidecar/src/filesystem.rs と crates/native-sidecar/src/execution/launch.rs の同期関数から始め、次に chunked_actor_sqlite プラグインを調査します。既存の vfs-consistency.nightly.test.ts を実行し、API で作成されたファイルがネイティブの guest プロセスによって上書きされるケースのカバレッジを拡張します。filesystem の読み取りと SQLite ベースの VM の再オープンの両方が guest の更新後の内容を返せば完了です。

索引モデルが issue の本文から書いたものです。

説明

Summary

With a sidecar-native chunked_actor_sqlite root filesystem, a file created through vm.filesystem.writeFile() is not updated in the filesystem API view after /bin/sh overwrites it.

The shell sees the new content, while vm.filesystem.readFile() deterministically returns the old content. Disposing and reopening the VM with the same SQLite database also returns the old content, so the guest update is not persisted to the authoritative VFS.

Minimal reproduction

import { mkdtemp, rm } from "node:fs/promises";
import { tmpdir } from "node:os";
import { join } from "node:path";
import { AgentOs } from "@rivet-dev/agentos";

const dir = await mkdtemp(join(tmpdir(), "agentos-fs-repro-"));
const sqlitePath = join(dir, "workspace.sqlite");
const sidecar = await AgentOs.createSidecar({ placement: "process" });
const vm = await AgentOs.create({
  sidecar: { kind: "explicit", handle: sidecar },
  database: { type: "sqlite_file", path: sqlitePath },
  rootFilesystem: {
    type: "native",
    plugin: {
      id: "chunked_actor_sqlite",
      config: { namespace: "root", uid: 1000, gid: 1000 },
    },
  },
  permissions: {
    fs: "allow",
    network: "deny",
    childProcess: "allow",
    process: "allow",
    env: "allow",
    binding: "deny",
  },
});

try {
  await vm.filesystem.mkdir("/workspace", { recursive: true });
  await vm.filesystem.writeFile("/workspace/shared.txt", "before");

  const proc = await vm.process.spawn(
    "/bin/sh",
    ["-c", "printf after > shared.txt; cat shared.txt"],
    { cwd: "/workspace", output: { retainEvents: true } },
  );
  await vm.process.wait(proc.pid);

  const events = await vm.process.getOutput(proc.pid);
  console.log(events); // shell output contains "after"
  console.log(
    Buffer.from(await vm.filesystem.readFile("/workspace/shared.txt")).toString(),
  ); // actual: "before", expected: "after"
} finally {
  await vm.dispose();
  await rm(dir, { recursive: true, force: true });
}

Equivalent minimal sequence:

filesystem.writeFile("/workspace/shared.txt", "before")
process.spawn("/bin/sh", ["-c", "printf after > shared.txt; cat shared.txt"])
filesystem.readFile("/workspace/shared.txt")

shell stdout: after
filesystem API: before

Reproduction matrix

Sequence Result
API write -> API read Correct
Shell create -> API read Correct
Shell create -> Shell overwrite -> API read Correct
API write -> Shell overwrite -> API read Stale pre-overwrite content
API write -> Shell remove/recreate -> API read ENOENT / not found

The failure remains when:

  • the replacement has a different byte length;
  • waiting 100 ms before the overwrite;
  • waiting 100 ms and touching the file after the overwrite;
  • disposing and reopening the VM against the same SQLite file.

If the initial file is also created through a guest process (cat > file via stdin), subsequent guest overwrites are visible through filesystem.readFile().

Expected behavior

Host filesystem APIs and guest processes should observe the same VFS. After the process exits successfully, filesystem.readFile() should return after, and reopening the persisted VM should retain after.

This matches the filesystem architecture documentation:

Host-side APIs (agent.writeFile, agent.readFile) enter the same VFS from the trusted side.

Suspected boundary

The behavior appears specific to native sidecar shadow-root reconciliation:

  • API WriteFile updates the kernel VFS and mirrors it into the process shadow root.
  • /bin/sh updates the shadow-root file successfully.
  • The process-exit shadow -> kernel reconciliation does not update the API-created inode in the authoritative VFS.

Likely relevant paths:

  • crates/native-sidecar/src/filesystem.rs
    • mirror_guest_filesystem_shadow_after_call
  • crates/native-sidecar/src/execution/launch.rs
    • sync_process_host_writes_to_kernel
    • sync_vm_shadow_root_to_kernel
    • sync_host_directory_tree_to_kernel_inner
  • crates/native-sidecar/src/plugins/chunked_actor_sqlite.rs

The existing vfs-consistency.nightly.test.ts exercises the runtime test kernel, but does not appear to cover the combination of a native process shadow and chunked_actor_sqlite after an API-created file is overwritten.

Environment

  • @rivet-dev/agentos: reproduced on 0.2.16-rc.1 and 0.2.16-rc.2
  • Node.js: v22.22.2
  • OS: Linux x86_64, kernel 6.6.98
  • glibc: 2.38
  • Root plugin: chunked_actor_sqlite
  • Reproduction rate: deterministic across repeated runs
主要言語
Rust
スター
4.8k
フォーク
270
平均マージ
14時間 28分
マージ済み PR（30日）
55

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rivet-dev/agentos のほかの issue

rivet-dev/agentos の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。