Renaming a file no longer rewrites the destination when the move…#270
Merged
Conversation
* fix(open-knowledge): write a renamed file's destination once, not twice A managed file rename moved the file, placing the source's bytes at the destination, and then unconditionally rewrote the destination with the reconciled content even when that content was byte-identical to what the move had just placed. Every rename therefore performed two full disk writes to the destination, and a rename that rewrote wiki-link references also briefly left the pre-rewrite bytes on disk where an external reader could observe them. Add a shared writeFileIfContentDiffers helper (raw-byte equality) and route the three synchronous rename-spine write sites through it: syncRenamedDocsToDisk, writeManagedRenameDocumentToDisk, and the doc-to-file source write. registerWrite stays unconditional at every site so the file watcher's self-suppression for the moved destination is preserved. A no-content-change rename now writes the destination exactly once; renames that genuinely rewrite content still write the final bytes. The byte-exact predicate is deliberate and distinct from persistence.ts's markdownSemanticallyUnchanged (which compares normalizeBridge-normalized content): byte equality under-skips relative to semantic equality, so it can only ever leave an occasional redundant write, never suppress a needed one. Adds an integration test asserting the single-write contract, with a process-scoped OTel tracer lifecycle so it stays order-independent under the single-process integration suite. * address review: forward-state comment-discipline phrasing in rename guard GitOrigin-RevId: 64289447a99935673a260d62ca77bc56beb53de4
![inkeep-internal-ci[bot]](https://avatars.githubusercontent.com/in/2806322?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Automated approval from agents-private public-mirror-sync (run: https://github.com/inkeep/agents-private/actions/runs/28191922114). Source of truth is the monorepo; direct edits on inkeep/open-knowledge are overwritten on next sync.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Renaming a file no longer rewrites the destination when the move already placed the final bytes there. A managed rename moves the file and then writes the reconciled content; previously that second write was unconditional, so a rename that did not change the file's content still wrote the destination twice. The rename spine now skips the rewrite when the reconciled content already matches what is on disk, so a no-content-change rename writes the destination exactly once. Renames that rewrite wiki-link references still write the destination twice — the move places the old bytes, then the link rewrite overwrites them — because that second write is doing real work.