fix(googlechat): support spaceType field for DM vs Space detection - #58993

Greptile Summary

This PR fixes a DM detection regression in the Google Chat integration caused by the deprecation of the space.type field ("DM" | "ROOM") in favor of space.spaceType ("DIRECT_MESSAGE" | "SPACE") and space.singleUserBotDm. When the legacy field is absent, the old check always fell through to isGroup = true, causing DMs to be processed as group messages and silently dropped when no group policy was configured.

Changes:

• types.ts: Adds spaceType?: string and singleUserBotDm?: boolean to GoogleChatSpace to model the newer API fields.
• monitor.ts: Replaces the single type-based check with a three-way && guard — isGroup is false (i.e. treated as DM) if any of the three fields signals a direct message. This correctly handles both legacy and current API payloads.

The logic is sound: all three conditions must be "not a DM signal" for the message to be classified as a group message, so any single DM indicator short-circuits to isGroup = false.

Confidence Score: 5/5

This PR is safe to merge — it is a targeted, well-reasoned bug fix with no regressions introduced.

The fix correctly uses conjunction (&&) so that any single DM indicator (type === 'DM', spaceType === 'DIRECT_MESSAGE', or singleUserBotDm === true) sets isGroup = false. All edge cases (legacy-only payload, modern-only payload, mixed payload, empty payload) are handled correctly. The type additions are minimal and safe. No existing behaviour is broken for group/space messages. All remaining observations are P2.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(googlechat): use spaceType and singl..." | Re-trigger Greptile}

Codex review: needs maintainer review before merge. Reviewed June 22, 2026, 4:37 AM ET / 08:37 UTC.

Summary
The branch adds Google Chat modern space classification and regression tests, while its current compare also carries stale-main maintenance changes outside the Google Chat surface.

PR surface: Source -41, Tests +289, Other +24. Total +272 across 26 files.

Reproducibility: Do we have a high-confidence way to reproduce the issue? Yes at source/report level: current main and v2026.6.9 only read space.type, while the discussion includes live Google Chat symptoms and the PR tests cover modern payload shapes; I did not run a fresh live Google Chat account test in this read-only review.

Review metrics: 1 noteworthy metric.

• Merge Refresh State: DIRTY; 4 ahead, 7 behind; no potential merge commit. The stale 26-file compare should not be treated as the final landing surface until the branch is refreshed against current main.

Stored data model
Persistent data-model change detected: database schema: extensions/qa-lab/src/test-file-scenario-runner.test.ts, migration/backfill/repair: qa/scenarios/memory/active-memory-preprompt-recall.yaml, persistent cache schema: extensions/qa-lab/src/providers/mock-openai/server.test.ts, persistent cache schema: qa/scenarios/runtime/long-context-cache-stability.yaml, serialized state: extensions/qa-lab/src/test-file-scenario-runner.test.ts, serialized state: qa/scenarios/memory/active-memory-preprompt-recall.yaml, and 4 more. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #58514
Summary: This PR is a focused candidate fix for modern Google Chat space metadata classification within the broader open Google Chat Space/group message-loss report.

Members:

• canonical: [Bug]: Google Chat: Space/Group messages silently ignored (DMs work correctly) #58514 - Open canonical report for Google Chat Space/group messages being accepted but not processed; this PR is linked from that issue and addresses one classifier root cause.
• partial_overlap: (googlechat) fix: space messaging, introduce deduplication, and update reply-to defaults #42330 - Closed unmerged Google Chat Space PR with broader dedupe/thread/default changes, not a viable replacement for this focused modern-field classifier fix.
• adjacent_distinct: Google Chat: agent-to-agent (bot↔bot) conversation doesn't work — a Chat app doesn't receive messages from another Chat app (same setup works on Discord) #90677 - Google Chat bot-to-bot delivery depends on whether Google emits app-authored message events, which is separate from this direct/group space metadata classifier.
• adjacent_distinct: [RFC] Multi-Session Architecture: Shared LLM + Isolated Sessions + Public Knowledge Base #48874 - The multi-session architecture RFC touches session isolation broadly but does not own this Google Chat transport classification bug.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Resolve the DIRTY/CONFLICTING merge state against current main.
• Keep the final merge result scoped to the three Google Chat classifier/type/test files.

Risk before merge

• [P1] Current PR head is DIRTY/CONFLICTING and diverged from current main, so maintainers need a fresh merge result before landing.
• [P1] The classifier feeds Google Chat direct/group access policy, session routing, and reply context; live Space/group delivery remains outside this scoped PR and should stay tracked by the canonical issue.

Maintainer options:

1. Refresh Branch To Current Main (recommended)
   Rebase or otherwise resolve the current DIRTY merge state so maintainers can verify that only the Google Chat classifier/type/test changes land.
2. Land The Scoped Classifier Fix
   After the merge result is clean, accept the remaining live-transport uncertainty because the patch is narrow, covered by focused route tests, and has a maintainer proof override.
3. Ask For Live Google Chat Proof
   Require a redacted live Google Chat DM or Space run before merge if maintainers want transport proof beyond the source-level reproduction and Testbox monitor tests.

Next step before merge

• [P2] Manual maintainer handling is needed because GitHub reports the PR as DIRTY/CONFLICTING; the underlying Google Chat fix remains valid and not yet on main or in v2026.6.9.

Security
Cleared: No concrete security or supply-chain concern was found in the scoped Google Chat classifier/type/test change; the stale compare needs merge refresh but does not add dependency or secret-handling changes by itself.

Reproduction confirmed on v2026.5.7 — additional diagnostic detail in support of PR #58993

Hit this exact issue this week. Posting the detail in case it's useful as the "real behavior proof" @clawsweeper is asking for on this PR.

Environment

• OpenClaw version: v2026.5.7, installed via npm install -g openclaw
• Node.js 25.6.0 (via Linuxbrew)
• OS: Ubuntu 24.04 LTS
• Run as a user systemd service (openclaw-gateway.service)
• Channel: Google Chat plugin, audienceType: app-url, behind Tailscale Funnel
• Tested with two separate Google Cloud projects:
  1. Original project where "Build this Chat app as a Workspace add-on" was ticked (greyed-out / locked)
  2. Fresh project with that checkbox explicitly unticked, new service account, app status set to Live

Symptoms

• DMs to the bot work end-to-end (pairing, replies, etc.).
• @mentions in a Google Chat Space silently produce nothing — no agent response, no error to the user, just Google's eventual "App is not responding" timeout in the UI.
• ADDED_TO_SPACE events do not appear to reach the agent either: removing and re-adding the bot to a Space produces zero observable activity in the gateway logs.

What Google's side sees

For the Workspace Add-on project, Cloud Logging shows Google attempting delivery and getting 400s back:

"deploymentFunction": "https://<redacted>/googlechat",
"deployment": "projects/chat/keys/<project-number>",
"error": {
  "code": 3,
  "message": "status code: 400, reason phrase: HTTP error response: HTTP/1.1 400 Bad Request\nResponse body: invalid payload"
}

Log type: type.googleapis.com/google.cloud.gsuiteaddons.logging.v1.GSuiteAddOnsLogEntry

For the standard Chat API project (add-on flag unticked), Cloud Logging shows zero error entries for Space @mentions even with "Log errors to Cloud Logging" enabled before re-adding the bot. The Chat API metrics page shows successful outbound calls (CreateMessage, ListSpaces, UpdateMessage) but no inbound errors. This is consistent with the hypothesis in this PR: Google delivers the payload, OpenClaw returns HTTP 200, OpenClaw silently classifies the message as a group and drops it during policy evaluation — so Google has nothing to log.

What OpenClaw's side sees

Running journalctl --user -u openclaw-gateway -f | grep -i googlechat and then @mentioning the bot in a Space produces zero googlechat-prefixed log lines — not just no group session creation, but no log activity at all from the plugin. Only googlechat:direct:* sessions appear, and only when sending DMs. This suggests the message is being dropped before any googlechat code path emits a log entry.

Other configurations ruled out (saves the next person time)

The following were tried during debugging and made no difference:

• Switching audienceType between app-url and project-number (with corresponding Google Cloud Console "Authentication audience" change)
• Setting appPrincipal to the service account's unique ID, then to the value Google reported in the "unexpected add-on principal" error
• Switching webhook URL between Tailscale Funnel and a reverse-proxied public hostname
• Removing/re-adding the bot to the Space multiple times
• Renaming the app to force Google to re-register the webhook
• Creating a completely fresh Google Cloud project from scratch with no add-on flag (per the issue's "tested with both" note)

Final config that produces the bug:

• Pure Chat API app, add-on flag never ticked
• audienceType: app-url, appPrincipal matching Google's signing principal
• groupPolicy: allowlist with the target space ID in the list (also tested with the default — same result)
• Visibility set to the workspace org
• DMs verified working in the same session, with the same auth, against the same webhook URL

Why this lines up with the fix

This PR's claim is that with modern Google Chat API payloads (where space.type is absent and only space.spaceType / space.singleUserBotDm are present), the existing classifier (space.type ?? "").toUpperCase() !== "DM" resolves to true and routes the message into the group path, where it's silently dropped by policy evaluation. That is exactly the observed behaviour: HTTP 200 to Google, no group session created, no error anywhere except a missing reply.

Note: still reproduces on v2026.5.7. No googlechat-specific changes in the 2026.4.x or 2026.5.x release notes that would address this — the only Google Chat work in 2026.5.x was externalising the plugin to npm.

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.
Where did the egg go?

* The egg game starts only after the PR passes the real-behavior proof check.

* Before that, no creature or rarity is rolled. The treat waits for real proof.

* This is still just collectible flavor: proof affects review readiness, not creature quality.

Hey, but I added a comment with all details: #58993 (comment)

Heads up: this PR needs to be updated against current main before the new required Dependency Guard check can pass.

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

This assigned pull request has been automatically marked as stale after being open for 27 days.
Please add updates or it will be closed.

Dependency Guard

This PR changes dependency-related files. Maintainers should confirm these changes are intentional.

Changed files:

• extensions/clickclack/npm-shrinkwrap.json
• extensions/fireworks/npm-shrinkwrap.json
• extensions/irc/npm-shrinkwrap.json
• extensions/mattermost/npm-shrinkwrap.json
• extensions/moonshot/npm-shrinkwrap.json
• extensions/searxng/npm-shrinkwrap.json
• extensions/signal/npm-shrinkwrap.json
• extensions/sms/npm-shrinkwrap.json
• extensions/tavily/npm-shrinkwrap.json
• extensions/tencent/npm-shrinkwrap.json
• extensions/venice/npm-shrinkwrap.json
• extensions/vercel-ai-gateway/npm-shrinkwrap.json
• extensions/zai/npm-shrinkwrap.json

Maintainer follow-up:

• Review whether the dependency changes are intentional.
• Inspect resolved package deltas when lockfile, shrinkwrap, or workspace dependency policy changes are present.
• Treat package-lock.json and npm-shrinkwrap.json diffs as security-review surfaces.
• Run pnpm deps:changes:report -- --base-ref origin/main --markdown /tmp/dependency-changes.md --json /tmp/dependency-changes.json locally for detailed release-style evidence.

Dependency graph changes are blocked

OpenClaw does not accept dependency graph changes through PRs unless a repository admin or security explicitly authorizes the current head SHA. Dependency updates are generated internally by maintainers so external PRs cannot change the resolved graph.

Detected dependency graph changes:

• extensions/clickclack/npm-shrinkwrap.json changed.
• extensions/fireworks/npm-shrinkwrap.json changed.
• extensions/irc/npm-shrinkwrap.json changed.
• extensions/mattermost/npm-shrinkwrap.json changed.
• extensions/moonshot/npm-shrinkwrap.json changed.
• extensions/searxng/npm-shrinkwrap.json changed.
• extensions/signal/npm-shrinkwrap.json changed.
• extensions/sms/npm-shrinkwrap.json changed.
• extensions/tavily/npm-shrinkwrap.json changed.
• extensions/tencent/npm-shrinkwrap.json changed.
• extensions/venice/npm-shrinkwrap.json changed.
• extensions/vercel-ai-gateway/npm-shrinkwrap.json changed.
• extensions/zai/npm-shrinkwrap.json changed.

To remove lockfile changes, restore them from the target branch:

git fetch origin
git checkout 'origin/main' -- 'extensions/clickclack/npm-shrinkwrap.json' 'extensions/fireworks/npm-shrinkwrap.json' 'extensions/irc/npm-shrinkwrap.json' 'extensions/mattermost/npm-shrinkwrap.json' 'extensions/moonshot/npm-shrinkwrap.json' 'extensions/searxng/npm-shrinkwrap.json' 'extensions/signal/npm-shrinkwrap.json' 'extensions/sms/npm-shrinkwrap.json' 'extensions/tavily/npm-shrinkwrap.json' 'extensions/tencent/npm-shrinkwrap.json' 'extensions/venice/npm-shrinkwrap.json' 'extensions/vercel-ai-gateway/npm-shrinkwrap.json' 'extensions/zai/npm-shrinkwrap.json'
git commit -m 'chore: remove dependency lockfile change'
git push

If this PR intentionally needs a dependency graph change, ask a repository admin or member of @openclaw/openclaw-secops to comment:

/allow-dependencies-change

The action will approve the current head SHA (467d289c32931cebadf4047f3332a347e0b681fd) when it reruns. A later push requires a fresh approval.

Merged via squash.

• Prepared head SHA: 467d289c32931cebadf4047f3332a347e0b681fd
• Merge commit: b9d254f2b05dfc53a83c0ad1fc38dc638966461c

Thanks @Starhappysh!