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

computerd: writes applied over sync do not reach inotify watchers on the FUSE mount

Aperta
  • Qualcosa non va?
#196 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@aron-cf ci sta già lavorando.

Dal 3/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

bug
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.

  1. Run inotifywait -m -r /workspace, then write a file on the host and pushOnce. The file content is correct on the mount and no event is printed. A local echo hi > /workspace/x prints CREATE, MODIFY and CLOSE_WRITE.
  2. Run astro dev (Astro 7, Vite 8, chokidar 4) on a project in the mount, with an HMR WebSocket client connected. Push an edit to src/site.ts: no HMR message arrives and the page keeps serving the old content.
  3. Push a new src/pages/nova.astro: GET /nova returns 404.
Environment
  • @cloudflare/computer 0.4.0, computerd from main at 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.afterApply becomes (applied: { readonly paths: readonly string[] }) => void | Promise<void>. The shim's afterApply ignores the argument, so existing callers keep compiling.
  • computerd registers afterApply: ({ paths }) => announceAppliedPaths(paths) when FUSE is mounted. utimes on the file covers edits; utimes on the parent covers creates and deletes. ENOENT is ignored.
  • The FUSE utimens handler 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 stat consistent with what the host wrote.
  • A privileged Docker test in the style of src/exec/runner.fuse.test.ts could run inotifywait and assert an event after a push.
Lingua principale
TypeScript
Stelle
9.5k
Fork
552
Merge medio
1g 21h
PR unite (30g)
42

Preparare l'ambiente

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 cloudflare/computer

Tutte le issue di cloudflare/computer

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.