connector-gmail: stop watch before re-up to avoid 400 conflict by KrisBraun · Pull Request #147 · plotday/plot

KrisBraun · 2026-05-21T16:16:17Z

Summary

setupMailboxWebhook always mints a fresh Pub/Sub topic (via createWebhook → new callback token → new topic name). The self-heal and renewal-fallback paths were calling users.watch() with that new topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair, which Gmail rejects with 400 INVALID_ARGUMENT — Only one user push notification client allowed per developer (call /stop then try again).
Tear down the existing watch and delete the orphaned topic up front, clearing mailbox_webhook state before any cleanup so partial failures don't leave lying pointers. upgrade() already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line.
Fixes a PostHog issue with 1188 occurrences across 1188 users (one error per user per scheduled self-heal/renewal that needed a re-up).

Test plan

pnpm build in connectors/gmail compiles clean.
After deploy, watch PostHog issue 019dbbae-84d9-76a0-92c5-e40171b32734 for new occurrences — should drop to zero.
Confirm Gmail push notifications continue to arrive for an existing user (watch already established before deploy) — selfHealCheck's next preemptive renewal should now succeed instead of throwing.
Confirm a fresh Gmail channel enable still establishes a new watch (no regression on the initial path).

🤖 Generated with Claude Code

Direct messages and inbound connection requests are different workflows (different cadence, different noise level, different response affordances). Make them two separately enable-able Plot channels instead of bundling them into one stream. - getChannels returns "messages" and "invitations" - onChannelEnabled / onChannelDisabled accept either, ignore unknown ids - syncBatch branches to syncMessages or syncInvitations - Removed singleChannel — multi-channel auto-discovery handles the rest - onNoteCreated and onThreadRead always target CHANNEL_MESSAGES (sends and read state only make sense for conversations) - meta.channelId on saved links now reflects which stream they came from

`setupMailboxWebhook` always creates a fresh Pub/Sub topic (createWebhook mints a new callback token, which becomes part of the topic name), so the self-heal and renewal-fallback paths were calling `users.watch()` with a NEW topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair. Gmail rejects that with 400 INVALID_ARGUMENT: "Only one user push notification client allowed per developer (call /stop then try again)" instead of replacing the existing registration. Stop the existing watch and delete the orphaned topic up front, clearing `mailbox_webhook` state before any cleanup so partial failures don't leave lying pointers behind. Existing `upgrade()` already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-21T16:16:17Z

Summary

setupMailboxWebhook always mints a fresh Pub/Sub topic (via createWebhook → new callback token → new topic name). The self-heal and renewal-fallback paths were calling users.watch() with that new topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair, which Gmail rejects with 400 INVALID_ARGUMENT — Only one user push notification client allowed per developer (call /stop then try again).
Tear down the existing watch and delete the orphaned topic up front, clearing mailbox_webhook state before any cleanup so partial failures don't leave lying pointers. upgrade() already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line.
Fixes a PostHog issue with 1188 occurrences across 1188 users (one error per user per scheduled self-heal/renewal that needed a re-up).

Test plan

pnpm build in connectors/gmail compiles clean.
After deploy, watch PostHog issue 019dbbae-84d9-76a0-92c5-e40171b32734 for new occurrences — should drop to zero.
Confirm Gmail push notifications continue to arrive for an existing user (watch already established before deploy) — selfHealCheck's next preemptive renewal should now succeed instead of throwing.
Confirm a fresh Gmail channel enable still establishes a new watch (no regression on the initial path).

🤖 Generated with Claude Code

Direct messages and inbound connection requests are different workflows (different cadence, different noise level, different response affordances). Make them two separately enable-able Plot channels instead of bundling them into one stream. - getChannels returns "messages" and "invitations" - onChannelEnabled / onChannelDisabled accept either, ignore unknown ids - syncBatch branches to syncMessages or syncInvitations - Removed singleChannel — multi-channel auto-discovery handles the rest - onNoteCreated and onThreadRead always target CHANNEL_MESSAGES (sends and read state only make sense for conversations) - meta.channelId on saved links now reflects which stream they came from

`setupMailboxWebhook` always creates a fresh Pub/Sub topic (createWebhook mints a new callback token, which becomes part of the topic name), so the self-heal and renewal-fallback paths were calling `users.watch()` with a NEW topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair. Gmail rejects that with 400 INVALID_ARGUMENT: "Only one user push notification client allowed per developer (call /stop then try again)" instead of replacing the existing registration. Stop the existing watch and delete the orphaned topic up front, clearing `mailbox_webhook` state before any cleanup so partial failures don't leave lying pointers behind. Existing `upgrade()` already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-21T16:16:17Z

Summary

setupMailboxWebhook always mints a fresh Pub/Sub topic (via createWebhook → new callback token → new topic name). The self-heal and renewal-fallback paths were calling users.watch() with that new topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair, which Gmail rejects with 400 INVALID_ARGUMENT — Only one user push notification client allowed per developer (call /stop then try again).
Tear down the existing watch and delete the orphaned topic up front, clearing mailbox_webhook state before any cleanup so partial failures don't leave lying pointers. upgrade() already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line.
Fixes a PostHog issue with 1188 occurrences across 1188 users (one error per user per scheduled self-heal/renewal that needed a re-up).

Test plan

pnpm build in connectors/gmail compiles clean.
After deploy, watch PostHog issue 019dbbae-84d9-76a0-92c5-e40171b32734 for new occurrences — should drop to zero.
Confirm Gmail push notifications continue to arrive for an existing user (watch already established before deploy) — selfHealCheck's next preemptive renewal should now succeed instead of throwing.
Confirm a fresh Gmail channel enable still establishes a new watch (no regression on the initial path).

🤖 Generated with Claude Code

Direct messages and inbound connection requests are different workflows (different cadence, different noise level, different response affordances). Make them two separately enable-able Plot channels instead of bundling them into one stream. - getChannels returns "messages" and "invitations" - onChannelEnabled / onChannelDisabled accept either, ignore unknown ids - syncBatch branches to syncMessages or syncInvitations - Removed singleChannel — multi-channel auto-discovery handles the rest - onNoteCreated and onThreadRead always target CHANNEL_MESSAGES (sends and read state only make sense for conversations) - meta.channelId on saved links now reflects which stream they came from

`setupMailboxWebhook` always creates a fresh Pub/Sub topic (createWebhook mints a new callback token, which becomes part of the topic name), so the self-heal and renewal-fallback paths were calling `users.watch()` with a NEW topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair. Gmail rejects that with 400 INVALID_ARGUMENT: "Only one user push notification client allowed per developer (call /stop then try again)" instead of replacing the existing registration. Stop the existing watch and delete the orphaned topic up front, clearing `mailbox_webhook` state before any cleanup so partial failures don't leave lying pointers behind. Existing `upgrade()` already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-21T16:16:17Z

Summary

setupMailboxWebhook always mints a fresh Pub/Sub topic (via createWebhook → new callback token → new topic name). The self-heal and renewal-fallback paths were calling users.watch() with that new topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair, which Gmail rejects with 400 INVALID_ARGUMENT — Only one user push notification client allowed per developer (call /stop then try again).
Tear down the existing watch and delete the orphaned topic up front, clearing mailbox_webhook state before any cleanup so partial failures don't leave lying pointers. upgrade() already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line.
Fixes a PostHog issue with 1188 occurrences across 1188 users (one error per user per scheduled self-heal/renewal that needed a re-up).

Test plan

pnpm build in connectors/gmail compiles clean.
After deploy, watch PostHog issue 019dbbae-84d9-76a0-92c5-e40171b32734 for new occurrences — should drop to zero.
Confirm Gmail push notifications continue to arrive for an existing user (watch already established before deploy) — selfHealCheck's next preemptive renewal should now succeed instead of throwing.
Confirm a fresh Gmail channel enable still establishes a new watch (no regression on the initial path).

🤖 Generated with Claude Code

Direct messages and inbound connection requests are different workflows (different cadence, different noise level, different response affordances). Make them two separately enable-able Plot channels instead of bundling them into one stream. - getChannels returns "messages" and "invitations" - onChannelEnabled / onChannelDisabled accept either, ignore unknown ids - syncBatch branches to syncMessages or syncInvitations - Removed singleChannel — multi-channel auto-discovery handles the rest - onNoteCreated and onThreadRead always target CHANNEL_MESSAGES (sends and read state only make sense for conversations) - meta.channelId on saved links now reflects which stream they came from

`setupMailboxWebhook` always creates a fresh Pub/Sub topic (createWebhook mints a new callback token, which becomes part of the topic name), so the self-heal and renewal-fallback paths were calling `users.watch()` with a NEW topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair. Gmail rejects that with 400 INVALID_ARGUMENT: "Only one user push notification client allowed per developer (call /stop then try again)" instead of replacing the existing registration. Stop the existing watch and delete the orphaned topic up front, clearing `mailbox_webhook` state before any cleanup so partial failures don't leave lying pointers behind. Existing `upgrade()` already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-21T16:16:17Z

Summary

setupMailboxWebhook always mints a fresh Pub/Sub topic (via createWebhook → new callback token → new topic name). The self-heal and renewal-fallback paths were calling users.watch() with that new topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair, which Gmail rejects with 400 INVALID_ARGUMENT — Only one user push notification client allowed per developer (call /stop then try again).
Tear down the existing watch and delete the orphaned topic up front, clearing mailbox_webhook state before any cleanup so partial failures don't leave lying pointers. upgrade() already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line.
Fixes a PostHog issue with 1188 occurrences across 1188 users (one error per user per scheduled self-heal/renewal that needed a re-up).

Test plan

pnpm build in connectors/gmail compiles clean.
After deploy, watch PostHog issue 019dbbae-84d9-76a0-92c5-e40171b32734 for new occurrences — should drop to zero.
Confirm Gmail push notifications continue to arrive for an existing user (watch already established before deploy) — selfHealCheck's next preemptive renewal should now succeed instead of throwing.
Confirm a fresh Gmail channel enable still establishes a new watch (no regression on the initial path).

🤖 Generated with Claude Code

Direct messages and inbound connection requests are different workflows (different cadence, different noise level, different response affordances). Make them two separately enable-able Plot channels instead of bundling them into one stream. - getChannels returns "messages" and "invitations" - onChannelEnabled / onChannelDisabled accept either, ignore unknown ids - syncBatch branches to syncMessages or syncInvitations - Removed singleChannel — multi-channel auto-discovery handles the rest - onNoteCreated and onThreadRead always target CHANNEL_MESSAGES (sends and read state only make sense for conversations) - meta.channelId on saved links now reflects which stream they came from

`setupMailboxWebhook` always creates a fresh Pub/Sub topic (createWebhook mints a new callback token, which becomes part of the topic name), so the self-heal and renewal-fallback paths were calling `users.watch()` with a NEW topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair. Gmail rejects that with 400 INVALID_ARGUMENT: "Only one user push notification client allowed per developer (call /stop then try again)" instead of replacing the existing registration. Stop the existing watch and delete the orphaned topic up front, clearing `mailbox_webhook` state before any cleanup so partial failures don't leave lying pointers behind. Existing `upgrade()` already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-21T16:16:17Z

Summary

setupMailboxWebhook always mints a fresh Pub/Sub topic (via createWebhook → new callback token → new topic name). The self-heal and renewal-fallback paths were calling users.watch() with that new topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair, which Gmail rejects with 400 INVALID_ARGUMENT — Only one user push notification client allowed per developer (call /stop then try again).
Tear down the existing watch and delete the orphaned topic up front, clearing mailbox_webhook state before any cleanup so partial failures don't leave lying pointers. upgrade() already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line.
Fixes a PostHog issue with 1188 occurrences across 1188 users (one error per user per scheduled self-heal/renewal that needed a re-up).

Test plan

pnpm build in connectors/gmail compiles clean.
After deploy, watch PostHog issue 019dbbae-84d9-76a0-92c5-e40171b32734 for new occurrences — should drop to zero.
Confirm Gmail push notifications continue to arrive for an existing user (watch already established before deploy) — selfHealCheck's next preemptive renewal should now succeed instead of throwing.
Confirm a fresh Gmail channel enable still establishes a new watch (no regression on the initial path).

🤖 Generated with Claude Code

Direct messages and inbound connection requests are different workflows (different cadence, different noise level, different response affordances). Make them two separately enable-able Plot channels instead of bundling them into one stream. - getChannels returns "messages" and "invitations" - onChannelEnabled / onChannelDisabled accept either, ignore unknown ids - syncBatch branches to syncMessages or syncInvitations - Removed singleChannel — multi-channel auto-discovery handles the rest - onNoteCreated and onThreadRead always target CHANNEL_MESSAGES (sends and read state only make sense for conversations) - meta.channelId on saved links now reflects which stream they came from

`setupMailboxWebhook` always creates a fresh Pub/Sub topic (createWebhook mints a new callback token, which becomes part of the topic name), so the self-heal and renewal-fallback paths were calling `users.watch()` with a NEW topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair. Gmail rejects that with 400 INVALID_ARGUMENT: "Only one user push notification client allowed per developer (call /stop then try again)" instead of replacing the existing registration. Stop the existing watch and delete the orphaned topic up front, clearing `mailbox_webhook` state before any cleanup so partial failures don't leave lying pointers behind. Existing `upgrade()` already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-21T16:16:17Z

Summary

setupMailboxWebhook always mints a fresh Pub/Sub topic (via createWebhook → new callback token → new topic name). The self-heal and renewal-fallback paths were calling users.watch() with that new topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair, which Gmail rejects with 400 INVALID_ARGUMENT — Only one user push notification client allowed per developer (call /stop then try again).
Tear down the existing watch and delete the orphaned topic up front, clearing mailbox_webhook state before any cleanup so partial failures don't leave lying pointers. upgrade() already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line.
Fixes a PostHog issue with 1188 occurrences across 1188 users (one error per user per scheduled self-heal/renewal that needed a re-up).

Test plan

pnpm build in connectors/gmail compiles clean.
After deploy, watch PostHog issue 019dbbae-84d9-76a0-92c5-e40171b32734 for new occurrences — should drop to zero.
Confirm Gmail push notifications continue to arrive for an existing user (watch already established before deploy) — selfHealCheck's next preemptive renewal should now succeed instead of throwing.
Confirm a fresh Gmail channel enable still establishes a new watch (no regression on the initial path).

🤖 Generated with Claude Code

Direct messages and inbound connection requests are different workflows (different cadence, different noise level, different response affordances). Make them two separately enable-able Plot channels instead of bundling them into one stream. - getChannels returns "messages" and "invitations" - onChannelEnabled / onChannelDisabled accept either, ignore unknown ids - syncBatch branches to syncMessages or syncInvitations - Removed singleChannel — multi-channel auto-discovery handles the rest - onNoteCreated and onThreadRead always target CHANNEL_MESSAGES (sends and read state only make sense for conversations) - meta.channelId on saved links now reflects which stream they came from

`setupMailboxWebhook` always creates a fresh Pub/Sub topic (createWebhook mints a new callback token, which becomes part of the topic name), so the self-heal and renewal-fallback paths were calling `users.watch()` with a NEW topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair. Gmail rejects that with 400 INVALID_ARGUMENT: "Only one user push notification client allowed per developer (call /stop then try again)" instead of replacing the existing registration. Stop the existing watch and delete the orphaned topic up front, clearing `mailbox_webhook` state before any cleanup so partial failures don't leave lying pointers behind. Existing `upgrade()` already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-05-21T16:16:17Z

Summary

setupMailboxWebhook always mints a fresh Pub/Sub topic (via createWebhook → new callback token → new topic name). The self-heal and renewal-fallback paths were calling users.watch() with that new topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair, which Gmail rejects with 400 INVALID_ARGUMENT — Only one user push notification client allowed per developer (call /stop then try again).
Tear down the existing watch and delete the orphaned topic up front, clearing mailbox_webhook state before any cleanup so partial failures don't leave lying pointers. upgrade() already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line.
Fixes a PostHog issue with 1188 occurrences across 1188 users (one error per user per scheduled self-heal/renewal that needed a re-up).

Test plan

pnpm build in connectors/gmail compiles clean.
After deploy, watch PostHog issue 019dbbae-84d9-76a0-92c5-e40171b32734 for new occurrences — should drop to zero.
Confirm Gmail push notifications continue to arrive for an existing user (watch already established before deploy) — selfHealCheck's next preemptive renewal should now succeed instead of throwing.
Confirm a fresh Gmail channel enable still establishes a new watch (no regression on the initial path).

🤖 Generated with Claude Code

Direct messages and inbound connection requests are different workflows (different cadence, different noise level, different response affordances). Make them two separately enable-able Plot channels instead of bundling them into one stream. - getChannels returns "messages" and "invitations" - onChannelEnabled / onChannelDisabled accept either, ignore unknown ids - syncBatch branches to syncMessages or syncInvitations - Removed singleChannel — multi-channel auto-discovery handles the rest - onNoteCreated and onThreadRead always target CHANNEL_MESSAGES (sends and read state only make sense for conversations) - meta.channelId on saved links now reflects which stream they came from

`setupMailboxWebhook` always creates a fresh Pub/Sub topic (createWebhook mints a new callback token, which becomes part of the topic name), so the self-heal and renewal-fallback paths were calling `users.watch()` with a NEW topic while Gmail still had the previous watch active for the same (mailbox, OAuth client) pair. Gmail rejects that with 400 INVALID_ARGUMENT: "Only one user push notification client allowed per developer (call /stop then try again)" instead of replacing the existing registration. Stop the existing watch and delete the orphaned topic up front, clearing `mailbox_webhook` state before any cleanup so partial failures don't leave lying pointers behind. Existing `upgrade()` already used this stop-then-set-up pattern; this brings the steady-state re-up paths in line. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisBraunand others added 2 commits May 21, 2026 12:11

KrisBraun merged commit b748686 into mainMay 21, 2026
1 check passed