Summary

• Problem: Google Chat threaded replies were carrying the inbound thread through a separate implicit threadId path, so replyToMode filtering on replyToId did not actually disable or limit threading.
• Why it matters: channels.googlechat.replyToMode: \"off\" still threaded replies, and \"first\" could keep threading follow-up payloads after the first reply.
• What changed: Google Chat now stores the thread name as the provider-specific current reply reference, the shared reply pipeline uses that reference for Google Chat payload threading, and routing no longer forwards Google Chat session threadId as an unconditional explicit thread target.
• What did NOT change (scope boundary): No config/schema changes for users, no non-Google-Chat behavior changes beyond the shared reply-reference plumbing needed to support provider-specific current reply IDs.

AI-assisted: yes. Testing: fully tested locally.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Google Chat: replyToMode: "off" does not suppress thread replies #42510
• Related fix(googlechat): preserve DM thread context #42603

User-visible / Behavior Changes

Google Chat now respects channels.googlechat.replyToMode in the shared reply pipeline:

• off keeps replies in the root conversation
• first only threads the first reply
• all preserves threaded replies consistently

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 24 / pnpm
• Model/provider: N/A
• Integration/channel (if any): Google Chat
• Relevant config (redacted): channels.googlechat.replyToMode=off|first|all

Steps

1. Receive a Google Chat inbound event with message.thread.name set.
2. Persist session metadata and build reply payloads through the shared reply pipeline.
3. Send immediate and routed replies for replyToMode=off, first, and all.

Expected

• off strips implicit threading.
• first uses the thread only once.
• all preserves the Google Chat thread reference consistently.

Actual

• Before this change, Google Chat could still thread replies through a preserved threadId path even after replyToId had been filtered out.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: focused Google Chat regression tests, full pnpm build, full pnpm test
• Edge cases checked: replyToMode=off, replyToMode=first, immediate monitor replies, routed shared-pipeline replies, typing-placeholder behavior for threaded replies
• What you did not verify: live Google Chat end-to-end against a real service account; pnpm check is currently blocked by unrelated upstream errors in src/config/model-alias-defaults.test.ts and src/cron/isolated-agent/run.ts

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert commit a2b73e0b
• Files/config to restore: extensions/googlechat/src/monitor.ts, src/auto-reply/reply/route-reply.ts, src/auto-reply/reply/agent-runner-utils.ts
• Known bad symptoms reviewers should watch for: Google Chat replies threading when replyToMode=off, or later replies continuing to thread when replyToMode=first

Risks and Mitigations

• Risk: shared reply plumbing now honors provider-specific CurrentMessageId for Google Chat, so regressions would show up as incorrect implicit threading rather than explicit send failures.
• Mitigation: added coverage at the monitor layer, shared payload builder, and route-reply boundary.

Made with Cursor