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

Upstream deletes from the container are dropped as stale: tombstoneIsStale compares revs from different peers' rev spaces

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

I maintainer di solito rispondono entro 1 giorno

@aron-cf ci sta già lavorando.

Dal 29/9/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

bug

Summary

Deletes made inside the container (rm, and therefore mv) are never applied to the Durable Object's VFS once the DO's local revision counter is ahead of computerd's. tombstoneIsStale compares revisions from two unrelated counters.

Environment

  • @cloudflare/computer 0.3.1 with computer-computerd-linux-x64:0.3.1.
  • withWorkspaceContainer + CloudflareContainerBackend, standard-1.
  • Same code on main (e5e28a7).

What happens

  1. A workspace has some history. Local writes via ws.fs.writeFile bump vfs_meta.rev, and so does every file pulled back from the container, because linkStagedChunksSync stamps it with a fresh local rev.
  2. ws.runtime.exec('rm x', { backend: 'linux' }).
  3. The container's ls no longer shows x, and result() reports sync.status: 'complete', pulled: 0.
  4. x is still in the DO's VFS. It is never re-pushed, because it did not change locally, so the two sides stay diverged. A mv a b arrives as "b created, a still present".

Files created in the container do propagate, because alreadyApplied compares manifest hashes, not revs.

Cause

packages/dofs/src/sync/apply.ts:

function tombstoneIsStale(db, entry) {
  const live = resolveInode(db, entry.path, { followSymlinks: false });
  if (live === null) return false;
  const row = db.one("SELECT rev FROM vfs_nodes WHERE inode = ?", live.inode);
  return row !== undefined && row.rev > entry.rev;
}
  • row.rev is the local node's rev (local vfs_meta.rev space).
  • For an upstream entry, entry.rev comes from the peer's change log (computerd's own counter).
  • packages/rpc/src/server.ts itself describes the push caller as "a sync peer with its own rev space".

computerd starts fresh after every sleep, so its counter is small, while the DO's grows with every write and pull. row.rev > entry.rev therefore holds for practically every path, and every container delete is dropped as "stale".

On main the predicate is also used by applyChangesSync (apply.ts:426), so the RPC server path has the same comparison. The same predicate runs on the computerd side for deletes pushed from the DO. It works today only because the DO's revs are larger, and would drop DO deletes if the container's counter were ever ahead.

Repro without a container

Drive a real Workspace over node:sqlite against a fake SyncRPC/ShellRPC peer whose counter starts at 1:

  1. Write /workspace/x a few times so the local rev is well above the peer's.
  2. Make the fake command append { kind: 'delete', path: '/workspace/x', rev: <peer rev> } to the peer's change log.
  3. Run ws.runtime.exec(..., { backend }).

Result: pulled === 0 and /workspace/x still exists.

Workaround we are running

One possible fix, which we applied as a local patch to dist/index.js: decide staleness by whether the peer has seen the local version. A node pushed to this backend (rev <= pushRev) yields to the peer's delete; a local change newer than the last completed push still wins.

function tombstoneIsStale(db, entry, backend) {
  const live = resolveInode(db, entry.path, { followSymlinks: false });
  if (live === null) return false;
  const row = db.one("SELECT rev FROM vfs_nodes WHERE inode = ?", live.inode);
  if (row === void 0) return false;
  return row.rev > readWatermark(db, "pushRev", backend ?? DEFAULT_BACKEND_ID);
}
// call site in applyChanges: tombstoneIsStale(db, entry, options.backend)

After a watermark divergence (pullOnceImpl resets pushRev to 0), deletes stay conservatively dropped until the next push re-establishes the watermark. We are not sure this is the right fix for the computerd side, or for pack pulls, but the cross-space comparison looks unintended.

Lingua principale
TypeScript
Stelle
9.5k
Fork
552
Merge medio
1g 17h
PR unite (30g)
50

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.