Skip to content

Fix docs_resolve_comment: post a reply with action="resolve" instead of comments.update#1

Open
Baho73 wants to merge 1 commit into
dbuxton:mainfrom
Baho73:fix/resolve-comment-via-replies-action
Open

Fix docs_resolve_comment: post a reply with action="resolve" instead of comments.update#1
Baho73 wants to merge 1 commit into
dbuxton:mainfrom
Baho73:fix/resolve-comment-via-replies-action

Conversation

@Baho73
Copy link
Copy Markdown

@Baho73 Baho73 commented May 30, 2026

Summary

  • Replace comments.update({resolved: True}) with replies.create(action="resolve") in docs_resolve_comment.
  • Always works whether or not the caller passes a reply string.
  • Returns the closing reply_id / reply_content for auditability.

Bug

The previous implementation always failed:

HttpError 400 ... "Comment content is required."

Two underlying issues in Drive v3 made the old code unusable:

  1. comments.update rejects any body that doesn't include a non-empty content field — even when the only change you want is resolved: True.
  2. Even with content re-sent, the resolved field on the Comment resource is effectively read-only via comments.update: empirically the call returns 200 but the comment stays open in the Drive UI and the API.

The canonical Drive v3 way to close a comment — and what the Docs UI does internally when you click "Resolve" — is to post a reply with action="resolve". So the fix is to always create such a reply.

Behavior

Caller Before After
docs_resolve_comment(doc, cid) 400 error replies.create(content="Resolved.", action="resolve"), returns ok
docs_resolve_comment(doc, cid, "thanks!") 400 error replies.create(content="thanks!", action="resolve"), returns ok + reply metadata

Drive requires non-empty content on every reply, so when the caller passes no reply we fall back to the short literal "Resolved.".

The two-step flow that used to be replies.create followed by comments.update is now a single atomic API call.

Test

Verified against a live Google Doc with two open comments:

  1. docs_resolve_comment(doc, cid_a) — no reply → returns {ok: true, reply_id, reply_content: "Resolved."}; docs_read_comments(include_resolved=True) confirms resolved: true.
  2. docs_resolve_comment(doc, cid_b, "Подтверждаю, фикс работает.") — with reply → returns the reply text in reply_content; comment is resolved: true and the reply is visible in the Docs UI.

Both cases also flip the comment to the resolved (struck-through) state in the Docs sidebar UI.

Notes

  • Diff is 19+ / 12− on server.py only. No new dependencies.
  • Tested on FastMCP 3.3.1 (the version uvx currently installs from main).
  • auth_setup.py and the rest of the toolset are untouched.

The previous implementation called `comments.update({resolved: True})`,
which fails in Drive v3 for two reasons:

1. The API rejects the call with HTTP 400 "Comment content is required"
   because every comments.update body must include a non-empty `content`
   field, even when the only intended change is the `resolved` flag.

2. Even if `content` is supplied (e.g. by re-sending the existing comment
   text), the `resolved` field on the Comment resource is effectively
   read-only via comments.update — empirically the call succeeds but the
   comment remains open in both the Drive UI and the API.

The canonical way to close a comment in Drive v3 — and what the Docs UI
does internally — is to post a reply with `action="resolve"`. This also
preserves any final-reply text the caller passed in, so it can replace
the previous two-step flow (replies.create + comments.update) with a
single atomic call.

When no `reply` text is provided, fall back to the short placeholder
"Resolved." because Drive requires non-empty `content` on every reply.

The function now also returns `reply_id` and `reply_content` so callers
can audit the closing reply.

Verified end-to-end against a live document: both the `reply=""` and
`reply="..."` paths flip `resolved` to true and the resulting comment is
shown as resolved in the Drive UI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant