Re-arm the tracked Docs revision after comment writes; one CHANGELOG entry per PR; 3.4.3 - #144
Conversation
…entry per PR; 3.4.3 Fix: addComment, replyToComment, resolveComment, updateComment and deleteComment each advance the Docs revisionId while Drive modifiedTime stays unchanged (measured live). The read tracker compares only modifiedTime, so the next body write went out with the pre-comment writeControl.requiredRevisionId and Google refused it as "changed since you last read it" with no external edit. Each comment tool now refreshes the tracked revision after its Drive write succeeds (readTracker.refreshRevision + comments/trackedRevision.js); the content snapshot and modifiedTime baseline are kept, and a failed probe keeps the old revision so the guard still fails closed. CHANGELOG.md is restructured to one entry per merged PR / direct commit with its own semantic version (2.0.1 .. 3.4.3); package.json moves 3.0.0 -> 3.4.3; RELEASING.md documents the per-PR convention. Tests: tests/commentRevisionRefresh.test.js; live/missions/verify-comment-collateral.mjs now drives all five comment tools and asserts a body write succeeds after each (PASS live 2026-09-02, sandbox empty after cleanup). live-coverage: 31/129/2. Co-Authored-By: Claude Code <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7a384e9659
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const res = await docs.documents.get({ documentId, fields: 'revisionId' }); | ||
| refreshRevision(documentId, res?.data?.revisionId); |
There was a problem hiding this comment.
When a collaborator changes the document body before this documents.get completes, the returned revision can include both the local comment and that external edit. Replacing the tracked revision with it while retaining the old content snapshot implicitly accepts the collaborator's change; if Drive's modifiedTime is still lagging—as guardMutation explicitly allows for—the next write carries this newly accepted revision and can overwrite content without reporting a conflict. Refreshing the revision therefore needs to verify that the body still matches the tracked snapshot, or require a reread when it cannot make that guarantee.
Useful? React with 👍 / 👎.
1 participant
Fix: comment tools left the tracked Docs revision stale
addComment,replyToComment,resolveComment,updateCommentanddeleteCommenteach advance the DocsrevisionIdwhile DrivemodifiedTimestays identical. Measured live on 2026-09-02:modifiedTime2026-09-02T19:53:11.311Zbefore and after all comment operations, Driveversion3 -> 4, DocsrevisionIdchanged each time.The read tracker compares only
modifiedTime, so after any comment operation the nextappendText/replaceDocumentWithMarkdownwent out with the pre-commentwriteControl.requiredRevisionId. Google returned 400 and the tool reported "This document (...) changed since you last read it" even though nobody else touched the document.Each comment tool now calls
refreshTrackedRevisionAfterComment()after its Drive write succeeds (dist/tools/docs/comments/trackedRevision.js, backed by the newreadTracker.refreshRevision()). The content snapshot andmodifiedTimebaseline are kept, so the read-before-write and content-change guards are untouched. A failed probe keeps the old revision, logs a warning, and leaves the comment result as-is, so the guard still fails closed. Untracked documents are never probed.Not covered here, follow-up issue to be filed: a collaborator's comment made in the Docs UI moves the revision the same way and nothing in-process can see it, so the next write still reports the conflict until the document is read again.
CHANGELOG: one entry per merged PR, package.json 3.0.0 -> 3.4.3
CHANGELOG.mdis restructured per the new convention: one entry per merged pull request or standalone direct commit, each with its own semantic version (2.0.1 for #81 through 3.4.2 for #143, and 3.4.3 for this PR). Every existing paragraph is preserved verbatim; entry order matchesgit log --first-parent v2.0.0..main.RELEASING.mddocuments the per-PR convention and now says thevalidatejob checks the #50 gate itself (since 3.3.3).Testing
tests/commentRevisionRefresh.test.js: for each of the five tools, a tracked doc gets exactly onedocuments.get({fields: 'revisionId'})probe and the tracker revision advances with content kept; untracked docs are not probed; a failing probe keeps the old revision and warns;resolveCommentrefreshes even when verification says the resolve did not persist; a failed comment write never probes.live/missions/verify-comment-collateral.mjsnow drives all five comment tools and asserts a body write succeeds after each with no re-read. PASS live 2026-09-02 (15 calls, only the intendedonCollateral='block'refusal, 1/1 cleaned up, sandbox empty after).npm run test:ci: 96 suites, 1419 passed, 2 skipped.npm audit --omit=dev: 0.npm pack --dry-run: 185 files, 396.6 kB.npm run live-coverage: 31 driven live / 129 unit only / 2 blocked by design.🤖 Generated with Claude Code