feat(google-chat): render clarify prompts as cards - #36068
Conversation
mxnstrexgl
left a comment
There was a problem hiding this comment.
LGTM — automated review passed. No security, quality, or test coverage issues detected.
d612a8b to
fcab9a0
Compare
mark_awaiting_text is the 'Other (type answer)' mode-flip, not a send-time setup call — invoking it in send_clarify forces the user's next message to be captured as the clarify response, racing the button-click path and bypassing the buttons entirely. Telegram calls it only in the 'other' callback branch; do the same here.
5065b0c to
8f60aa1
Compare
teknium1
left a comment
There was a problem hiding this comment.
Thanks for isolating the Cards v2 renderer and preserving the typed-reply path. This slice is not operational on its own, however.
Problems
plugins/platforms/google_chat/adapter.py:2067emitshermes_clarify, but current main's Pub/Sub handler explicitly ACKs and discards card/widget events atplugins/platforms/google_chat/adapter.py:1211-1217. Thus a click cannot resolve the pending clarify, despite the adapter contract requiring button taps to reachtools.clarify_gateway.resolve_gateway_clarify(gateway/platforms/ADDING_A_PLATFORM.md:119). The PR body correctly identifies #36069 as the missing callback work._clarify_stateis written atplugins/platforms/google_chat/adapter.py:2105, but this PR has no reader or cleanup path. Successful cards accumulate state until restart.
Suggested changes
- Salvage this together with a tested inbound card-click resolver, including the
Othertext-entry transition. - Add an inbound-event test that verifies a card click resolves the clarify and removes its state.
Automated hermes-sweeper review.
| buttons.append( | ||
| { | ||
| "text": label, | ||
| "action": "hermes_clarify", |
There was a problem hiding this comment.
This action has no receiver in this PR: current main ACKs and discards Google Chat card/widget events at plugins/platforms/google_chat/adapter.py:1211-1217. Please land it with inbound dispatch to resolve_gateway_clarify, or retain the text renderer until that callback path is available.
| ) | ||
| result = await self.send_card(chat_id, card, metadata=metadata) | ||
| if result.success: | ||
| self._clarify_state[clarify_id] = session_key |
There was a problem hiding this comment.
This state is never read or cleared by this PR, so every successful clarify card leaves an entry until adapter restart. Move it with the callback implementation or add lifecycle cleanup and an inbound-resolution test.
What does this PR do?
Renders Google Chat
clarify()prompts with choices as Chat cards with buttons, while preserving the existing text fallback path.This makes Google Chat clarify prompts easier to answer from the Chat UI without changing the underlying clarify tool contract.
Related Google Chat PRs: #36027, #36035, #36061. Card-click callback handling is intentionally split into a follow-up PR.
Related Issue
N/A — focused Google Chat UX improvement for existing gateway clarify prompts.
Type of Change
Changes Made
plugins/platforms/google_chat/adapter.py: add a small Cards v2 renderer for constrained card specs.plugins/platforms/google_chat/adapter.py: addsend_card()for postingcardsV2payloads with thread metadata.plugins/platforms/google_chat/adapter.py: overridesend_clarify()to render choice prompts as Google Chat cards and preserve text-response fallback.tests/gateway/test_google_chat.py: cover card rendering, threadedsend_card(), and clarify card payloads.How to Test
python -m py_compile plugins/platforms/google_chat/adapter.py tests/gateway/test_google_chat.pygit diff --checkscripts/run_tests.sh tests/gateway/test_google_chat.pypython /root/.codex/skills/hermes-upstream-pr/scripts/pr_preflight.py --base upstream/mainChecklist
Code
Documentation & Housekeeping
cli-config.yaml.exampleupdate N/A.CONTRIBUTING.md/AGENTS.mdupdate N/A.Related PRs
Screenshots / Logs
Validation passed locally: