Python edits to filesystem.writeFile-created files are reverted by shadow reconciliation
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- backend, operating-systems
Hướng nghiên cứu
Start by reading service_owned_python_filesystem_rpc_request and compare the Python Write handling with the wire WriteFile handler that mirrors bytes into the staging tree. The issue says a regression is being prepared for regular writes, read-modify-write, and atomic replacement; verify that host reads after execution preserve Python's edits. A linked open pull request already addresses this work.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
Python edits to a file seeded with vm.filesystem.writeFile() can succeed and be visible inside the Python execution, then silently revert to the API-seeded bytes when the host reads the file after execution.
This is the Python VFS bridge counterpart of #1961. The JavaScript fix in #1981 is present in the tested source, but Python uses a different write handler. Related: the shell/WASM report #1901 is still open. This report is specifically about Python writes, not the shell-to-Python child-process issue #2012.
Reproduction
With a VM in which Python execution is available:
await vm.filesystem.mkdir('/workspace', { recursive: true });
await vm.filesystem.writeFile(
'/workspace/data.txt', new TextEncoder().encode('original\n'),
);
const result = await vm.python.execute(`
from pathlib import Path
p = Path('/workspace/data.txt')
p.write_text('EDITED\\n')
print(p.read_text(), end='')
`, { output: { capture: 'all' } });
console.log(result.stdout); // EDITED\n
console.log(new TextDecoder().decode(
await vm.filesystem.readFile('/workspace/data.txt'),
)); // original\n -- unexpected
Expected: both reads return EDITED\n. Actual: Python sees its edit and exits successfully, but the following filesystem API read returns original\n; subsequent executions also see the reverted data. A read-modify-write (p.write_text(p.read_text() + 'added\\n')) has the same problem. Seeding a fresh file through Python rather than through the filesystem API avoided the stale API-created shadow in our tests.
Verification
- Reproduced with the published 0.2.22 packages on Linux arm64, including embedded
AgentOs.create()without HTTP, Rivet actors, or PostgreSQL. That setup used a command-registration workaround to enable Python; this report starts after Python executes successfully. - Independently reproduced against unpatched upstream source at
c3698e6a60be0a6fed61d411779930e0a7753fc8using the native-sidecar Rust wire harness andExecuteRequest { runtime: Python, ... }. This bypasses SDK interpreter-command registration entirely. - The new regression fails with
left: "original\n",right: "EDITED\n"on its first post-execution host read. The bridge bundle was built from that checkout; no application storage service is needed.
Suspected cause
The wire WriteFile handler mirrors bytes into the VM's root staging/shadow tree. service_owned_python_filesystem_rpc_request handles Python Write by updating only the kernel VFS. Subsequent shadow-to-kernel reconciliation imports the unchanged staging copy and overwrites the newer Python bytes. The JavaScript mirroring change in #1981 does not run on this Python RPC path.
I am preparing a focused fix and regressions for Python writes, including read-modify-write and atomic replacement. Python append-position/truncate behavior and shell/WASM shadow writes are separate from this fix.
- Ngôn ngữ chính
- Rust
- Star
- 4.7k
- Fork
- 263
- Merge trung bình
- 8 giờ 57 phút
- Pull request đã merge (30 ngày)
- 30
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của rivet-dev/agentos
-
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 32/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 66/100
rivet-dev/agentos#1994 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Inline JavaScript resolves dynamic import() from / instead of the working directoryCó thể đã có người làm @mittal-parth đã nhận 18 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của rivet-dev/agentos
Issue tương tự
-
status:needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
agentic-os-org/ANOLISA#6742 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
Kc1t/alethe-agents#312 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
api: storage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
googleapis/google-cloud-rust#7153 ·
Maintainer thường phản hồi trong vòng 1 ngày