We are subscribed to google.workspace.drive.comment.v3.created and google.workspace.drive.comment.v3.edited.
Regular comments generate events successfully.
Comments created via Google Docs “Assign to” do not generate any Workspace Events API notifications.
Is this expected behavior, a documented limitation, or a bug?
Not a documented limitation, and the API’s own payload argues it should work. My read: this is an undocumented gap in the event pipeline, effectively a bug, though Google has not classified it publicly either way.
Why it isn’t “expected”
The reference defines the event as “A user creates a comment on a file,” with no carve-out for assigned comments. More telling, the comment event’s resource data has a dedicated assignee_email_address field, and the Drive v3 Comment resource exposes assigneeEmailAddress as output-only. A field that exists specifically to carry the assignee is hard to square with assigned comments being deliberately excluded from the events that carry it. Nothing in the Drive events guide or the Workspace Events release notes mentions the exclusion.
Why it probably happens
Google’s own activity model treats an assignment as a different kind of comment from a post. In the Drive Activity API v2, Comment has three subtypes: Post, Assignment, and Suggestion. Assignment carries assignedUser and distinguishes initial assignment from reassignment. Docs “Assign to” writes the assignment kind, and the Events pipeline looks like it only fires on posts. Supporting that reading: there is no assigned or reassigned event type anywhere in the Drive event list, so assignment changes on an existing comment have no event either.
Two tests to pin down which it is
comments.list with fields=comments(id,content,assigneeEmailAddress,modifiedTime). If the comment is there with assigneeEmailAddress populated and no event arrived, it is an emission gap worth filing. If the comment never appears, it is a data-model exclusion and no event is ever coming.created fires), then assign it. If the assignment produces no edited event, assignment transitions are invisible to the pipeline entirely, not just at creation.What to ship in the meantime
The Drive Activity API v2 is the only surface that models assignment natively. Query activity.query scoped to the file or folder, filter on detail.comment, and read the assignment subtypes for assign and reassign. Cheaper alternative: poll comments.list and diff assigneeEmailAddress per comment ID, which catches both assignment and reassignment in one call per file.
I would keep the events subscription for low-latency regular comments and add a reconciliation sweep on one of the above for assignments, rather than moving everything to polling.
We’ve tested the scenarios you outlined and can confirm the following:
comments.list), including the populated assigneeEmailAddress field.Based on our testing, the assignment data clearly exists and is accessible through the Comments API, but the event is not being emitted through the Workspace Events pipeline. This aligns with your hypothesis that there may be a gap in event generation or propagation for assigned comments specifically, rather than the assignment itself being unavailable through the Drive APIs.
Regarding the suggested reconciliation approach, we already employ a similar mechanism today as a fallback. While periodically querying comment data can eventually identify newly assigned comments, it does not provide the near real-time experience that Workspace Events would ideally enable. Additionally, continuously polling comments across a large number of documents introduces scalability concerns and increasing operational overhead as the number of monitored documents grows.
Given the behavior observed, do you have any recommendations on how this can be formally raised with Google for investigation? In particular, is there a preferred channel for reporting what appears to be a gap or defect in Workspace Events behavior?
If this is ultimately determined to be a product issue, is there any mechanism for tracking the investigation and receiving updates from the Google team?
At present, the available workaround is functional but does not adequately address the latency and scalability requirements of our use case, so we would be interested in understanding the appropriate path to engage Google and pursue a long-term resolution.
Google’s Issue Tracker, more specifically the dedicated Events API issues page. See link below: