Skip to content

fix(web): closing a file tab no longer overwrites newer changes - #8632

Open
walid-baharwal wants to merge 1 commit into
pingdotgg:mainfrom
walid-baharwal:fix/file-tab-close-stale-write
Open

fix(web): closing a file tab no longer overwrites newer changes#8632
walid-baharwal wants to merge 1 commit into
pingdotgg:mainfrom
walid-baharwal:fix/file-tab-close-stale-write

Conversation

@walid-baharwal

@walid-baharwal walid-baharwal commented Aug 29, 2026

Copy link
Copy Markdown
Contributor

What Changed

FileSaveCoordinator now tracks the revision it last confirmed on disk and flushes on dispose only when the buffer holds an edit newer than that. Previously dispose flushed whenever latestRevision > 0, and latestRevision was only ever incremented, never reconciled with what was actually written.

Why

Closing or switching a file tab re-wrote the tab's remembered buffer even when the debounce had already saved it. If the file changed on disk after that save — an agent turn, another client, a shell — the close replaced the newer content with the stale buffer, with nothing in the UI or the event store recording the loss. Fixes #8475.

Flush-on-dispose is deliberate: it saves edits made inside the 500 ms debounce window right before a tab closes. That still works, and a write that failed before the close is still retried. A write already in flight when the tab closes is unchanged from before this PR: if it fails and no newer edit exists, it is not retried.

Full disk-staleness reconciliation is deliberately out of scope. ProjectWriteFileInput carries only cwd, relativePath and contents, so a write precondition would be a contract change across server, web, mobile and desktop. The remaining case: an edit made inside the debounce window that races an external write still flushes.

Related: #8424 touches this file for a different bug and, as a side effect, would also fix #8475 by zeroing latestRevision on success. This PR uses a separate counter instead, because latestRevision is also the in-flight ordering token — zeroing it makes the revision === latestRevision check after a successful write never hold. Whichever lands second needs a rebase.

UI Changes

None. Nothing rendered changes; the observable difference is the file's contents on disk after a tab close.

Before (main) and after, same steps — open probe.txt, type a character, wait past the debounce, delete it, wait, then echo APPENDED_BY_AGENT >> probe.txt from a shell, then close the tab:

=== BEFORE: disk after closing the file tab ===
line one
line two                      <- APPENDED_BY_AGENT destroyed

=== AFTER: disk after closing the file tab ===
line one
line two
APPENDED_BY_AGENT             <- survives

Verification

vp test run apps/web/src/components/files/fileSaveCoordinator.test.ts   # 8 passed
cd apps/web && pnpm typecheck
vp lint apps/web/src/components/files/fileSaveCoordinator.ts apps/web/src/components/files/fileSaveCoordinator.test.ts
vp format --check apps/web/src/components/files/fileSaveCoordinator.ts apps/web/src/components/files/fileSaveCoordinator.test.ts
git diff --check

does not rewrite already saved contents when the editor closes fails on main (expected "vi.fn()" to be called once, but got 2 times) and passes here. The other new cases cover dispose inside the debounce window, dispose while a write is in flight (with and without a newer edit), and retry after a failed write. Also verified by hand in a dev client against a scratch --home-dir, per the transcript above.

Checklist

  • This PR is small and focused
  • I explained what changed and why
  • I included before/after screenshots for any UI changes (N/A — nothing rendered changed; disk transcript above)
  • I included a video for animation/interaction changes (N/A)

Model: Claude Opus 5 (1M context). Harness: Claude Code.


Note

Medium Risk
Changes file persistence on tab close in a coordinator used by the editor; incorrect logic could lose edits or skip needed flushes, but scope is small and well-tested.

Overview
Fixes closing a file tab re-writing disk with a stale buffer after the debounce had already persisted the same revision—e.g. when the file changed externally afterward (#8475).

FileSaveCoordinator now keeps a persistedRevision updated on each successful persist and only runs flush-on-dispose when latestRevision > persistedRevision, instead of whenever latestRevision > 0. Flush-on-close behavior is preserved for edits still inside the debounce window, newer edits while a write is in flight, and retries after a failed write; it does not trigger a second write when the last edit was already confirmed.

Tests add coverage for those dispose/close scenarios.

Reviewed by Cursor Bugbot for commit 38876e5. Bugbot is set up for automated code reviews on this repo. Configure here.

Note

Fix FileSaveCoordinator.dispose overwriting newer changes by tracking persistedRevision

  • Adds persistedRevision field to FileSaveCoordinator to track the last successfully saved revision, set on each successful persist in persistLatest
  • Changes dispose to only flush when latestRevision > persistedRevision, so closing a tab no longer rewrites content that was already saved
  • Failed writes leave persistedRevision unchanged, allowing dispose to retry pending or failed writes
  • Behavioral Change: dispose now skips persisting when all edits are already confirmed; previously it always persisted if latestRevision > 0

Macroscope summarized 38876e5.

The file editor's save coordinator only ever incremented its edit
revision, so `dispose` treated any tab that had been edited once as
holding unsaved work. Closing or switching that tab re-wrote the
remembered buffer, replacing whatever had changed the file since the
last save.

Track the revision confirmed on disk and flush on dispose only when the
buffer holds a newer edit. Edits made inside the debounce window are
still saved on close, and a write that failed before the close is still
retried.

Fixes pingdotgg#8475
@coderabbitai

coderabbitai Bot commented Aug 29, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: cab90719-25eb-42d3-9ed8-cf43e07cc8f3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:XS 0-9 changed lines (additions + deletions). labels Aug 29, 2026
@macroscopeapp

macroscopeapp Bot commented Aug 29, 2026

Copy link
Copy Markdown
Contributor

Approvability

Verdict: Approved at 38876e5

Macroscope's review found this PR approvable — This is a narrowly scoped file-save bug fix that prevents a redundant close-time write after a revision is already persisted, while preserving unsaved-edit flushing and retry behavior. Production changes are confined to the save coordinator, with targeted tests covering the affected lifecycle cases and no product-default or schema changes.

You can add or adjust custom eligibility rules. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:XS 0-9 changed lines (additions + deletions). vouch:unvouched PR author is not yet trusted in the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Closing a file tab overwrites newer on-disk changes

1 participant