computerd: writes applied over sync do not reach inotify watchers on the FUSE mount
メンテナーはふだん 1 日以内に返信
@aron-cf がすでに取り組んでいます。
2026年10月3日 から。
評価
この issue はまだ評価されていません。
説明
Describe the bug
When the host pushes a change to computerd, the entry is applied straight into the in-container VFS. Reads through the FUSE mount return the new bytes, but the kernel never sees an operation on the path, so no inotify event is emitted. File watchers inside the container (Vite/chokidar, astro dev, tsc --watch, node --watch) never notice the change.
The workflow this breaks: an agent edits files through workspace.fs (or the worker-shell backend) while a dev server runs in the container. Hot module replacement never fires, and new files are not picked up by the dev server's router until it restarts.
Writes made inside the container through the mount do emit events, because they go through the kernel.
Expected behavior
A change applied by the sync push handler is visible to inotify watchers on the mount, the same way a local write is, without syncing anything back to the host.
Steps to reproduce
computerd built from main (2f76387), FUSE_MOUNT=fuse, MOUNT_POINT=/workspace. The host side is driven by pushOnce, pullOnce and reconcileWatermarks from @cloudflare/computer-rpc/driver on a SQLiteTestStorage database, as in script/computerd-soak.mjs.
- Run
inotifywait -m -r /workspace, then write a file on the host andpushOnce. The file content is correct on the mount and no event is printed. A localecho hi > /workspace/xprints CREATE, MODIFY and CLOSE_WRITE. - Run
astro dev(Astro 7, Vite 8, chokidar 4) on a project in the mount, with an HMR WebSocket client connected. Push an edit tosrc/site.ts: no HMR message arrives and the page keeps serving the old content. - Push a new
src/pages/nova.astro:GET /novareturns 404.
Environment
@cloudflare/computer0.4.0,computerdfrommainat 2f76387- Linux x86_64 (kernel 6.18), Node 22, libfuse 2.9.9, real FUSE (
/dev/fuse) - Host side run locally with the sync driver; not yet reproduced on Cloudflare Containers
Proposed fix
Pass the applied paths to the existing afterApply hook, and in the real FUSE backend set the times of each applied path and its parent directory through the mount after the batch commits:
ServerOptions.afterApplybecomes(applied: { readonly paths: readonly string[] }) => void | Promise<void>. The shim'safterApplyignores the argument, so existing callers keep compiling.computerdregistersafterApply: ({ paths }) => announceAppliedPaths(paths)when FUSE is mounted.utimeson the file covers edits;utimeson the parent covers creates and deletes. ENOENT is ignored.- The FUSE
utimenshandler only records times in driver metadata, so the poke does not produce a VFS change and nothing syncs back.
The patch is about 30 lines in packages/rpc/src/server.ts and packages/computerd/src/cli/computerd.ts. I can share it as a diff or open a pull request if a maintainer asks for one.
Results with the patch
| Case | Without patch | With patch |
|---|---|---|
| Pushed edit to an imported module | no HMR, stale page | full-reload 25 ms after the push, page updated |
| Pushed new page | /nova returns 404 |
/nova returns 200 |
| Pull after the poke | 0 entries | 0 entries (no echo) |
tsc --noEmit for packages/rpc and packages/computerd reports the same pre-existing errors in test files before and after the change.
Compatibility and open questions
- The hook signature change is additive for implementers of
afterApply. - Large batches: touching every applied path may be worth bounding, for example to the parent directories once a batch passes some size.
- The touch sets the times to now. Using the VFS mtime instead would keep
statconsistent with what the host wrote. - A privileged Docker test in the style of
src/exec/runner.fuse.test.tscould runinotifywaitand assert an event after a push.
- 主要言語
- TypeScript
- スター
- 9.5k
- フォーク
- 552
- 平均マージ
- 2日 6時間
- マージ済み PR（30日）
- 47
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
cloudflare/computer のほかの issue
-
Sync planning scans the full pending change set before yielding; repeated Durable Object CPU-limit failures対応中かも @aron-cf が 1 日前に担当しました。 オープンbug
cloudflare/computer#225 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
cloudflare/computer#224 · コメント 5 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Always run the "next" computerd workflow on push to the `release` branch対応中かも @aron-cf が 2 日前に担当しました。 オープンbug
cloudflare/computer#222 · コメント 2 件 · リアクション 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
Make just-bash and acorn optional peer dependencies, pulled in only by the backend that needs themオープンenhancement
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
cloudflare/computer#220 · コメント 3 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Workspace namespaces: more than one Workspace per Durable Object storage対応中かも @aron-cf が 3 日前に担当しました。 オープンenhancement
cloudflare/computer#219 · コメント 1 件 · リアクション 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
cloudflare/computer の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
cline/mcp-marketplace#2932 ·
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
lingdojo/kana-dojo#32188 · コメント 1 件 · リアクション 5 件 ·
メンテナーはふだん 1 日以内に返信
-
triage
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
Portkey-AI/gateway#1844 ·
メンテナーはふだん 1 日以内に返信
-
needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 61/100
rjsf-team/react-jsonschema-form#5495 ·
メンテナーはふだん 2 日以内に返信