Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#196 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@aron-cf ya está trabajando en esto.

Desde el 3/10/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
9.5k
Forks
552
Merge medio
2 d 4 h
PR fusionados (30 d)
49

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudflare/computer

Todos los issues de cloudflare/computer

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.