connector-google-contacts: fail-soft on missing token

[KrisBraun]

Summary

• onChannelEnabled, getContacts, startSync in connectors/google-contacts/src/google-contacts.ts all threw "No Google authentication token available" when integrations.get(channelId) returned null. The same connector already handles this case correctly in syncBatch (lines 108-117) — "abort instead of throwing to prevent infinite queue retries." This brings the three remaining entry points in line: log + return (or return [] for getContacts), don't throw.
• The throws were surfacing as "Recovery dispatch failed for connection" warns at the api worker level, blocking the parent connector's recovery dispatch from completing.

Why

We hit this on prod tonight while diagnosing why kris@plot.day's Personal Google Calendar wasn't recovering after a stuck-sync repair. PostHog log at 2026-04-28T22:32:28Z revealed the unwrapped __TWIST_ERROR__: "No Google authentication token available" thrown at _GoogleContacts.onChannelEnabled — bubbling up from a recovery dispatch on a parent GCal twist.

The deeper cause behind the missing token is a real model mismatch worth following up on:

GoogleContacts is built as a sub-connector via Integrations.MergeScopes. getChannels() returns a static {id: "contacts"}, so integrations.get("contacts") looks up a token keyed by "contacts" — but the parent's OAuth flow stored tokens keyed by calendar/drive/gmail channel ids. The lookup misses by design even when OAuth is healthy. The right long-term fix is to route sub-connector token lookups through the parent's token store on miss; that's a runtime change in @plotday/twister/api worker and should land separately.

For now, fail-soft restores reliability: contacts won't sync until the next OAuth touchpoint or daily refresh, which is acceptable for the contacts-as-side-effect use case and unblocks the parent connector's recovery for the two affected users (kris@plot.day Personal GCal, cameronandrewpak@gmail.com).

Test plan

• After deploy, re-arm recovery_pending=true on the affected twist_instance_connection rows
• Confirm next 30-min recoverPendingConnections cron reaches the parent GCal connector's onChannelEnabled without surfacing a "Recovery dispatch failed" warn
• Confirm link count starts climbing on 019dac4d-96cc-7c24-9d6c-2a45854cbf42
• Spot-check PostHog logs for the new "Auth token missing for ... during onChannelEnabled, skipping" warn — confirms fail-soft path was taken

🤖 Generated with Claude Code

[KrisBraun]

Summary

• onChannelEnabled, getContacts, startSync in connectors/google-contacts/src/google-contacts.ts all threw "No Google authentication token available" when integrations.get(channelId) returned null. The same connector already handles this case correctly in syncBatch (lines 108-117) — "abort instead of throwing to prevent infinite queue retries." This brings the three remaining entry points in line: log + return (or return [] for getContacts), don't throw.
• The throws were surfacing as "Recovery dispatch failed for connection" warns at the api worker level, blocking the parent connector's recovery dispatch from completing.

Why

We hit this on prod tonight while diagnosing why kris@plot.day's Personal Google Calendar wasn't recovering after a stuck-sync repair. PostHog log at 2026-04-28T22:32:28Z revealed the unwrapped __TWIST_ERROR__: "No Google authentication token available" thrown at _GoogleContacts.onChannelEnabled — bubbling up from a recovery dispatch on a parent GCal twist.

The deeper cause behind the missing token is a real model mismatch worth following up on:

GoogleContacts is built as a sub-connector via Integrations.MergeScopes. getChannels() returns a static {id: "contacts"}, so integrations.get("contacts") looks up a token keyed by "contacts" — but the parent's OAuth flow stored tokens keyed by calendar/drive/gmail channel ids. The lookup misses by design even when OAuth is healthy. The right long-term fix is to route sub-connector token lookups through the parent's token store on miss; that's a runtime change in @plotday/twister/api worker and should land separately.

For now, fail-soft restores reliability: contacts won't sync until the next OAuth touchpoint or daily refresh, which is acceptable for the contacts-as-side-effect use case and unblocks the parent connector's recovery for the two affected users (kris@plot.day Personal GCal, cameronandrewpak@gmail.com).

Test plan

• After deploy, re-arm recovery_pending=true on the affected twist_instance_connection rows
• Confirm next 30-min recoverPendingConnections cron reaches the parent GCal connector's onChannelEnabled without surfacing a "Recovery dispatch failed" warn
• Confirm link count starts climbing on 019dac4d-96cc-7c24-9d6c-2a45854cbf42
• Spot-check PostHog logs for the new "Auth token missing for ... during onChannelEnabled, skipping" warn — confirms fail-soft path was taken

🤖 Generated with Claude Code

[KrisBraun]

Summary

• onChannelEnabled, getContacts, startSync in connectors/google-contacts/src/google-contacts.ts all threw "No Google authentication token available" when integrations.get(channelId) returned null. The same connector already handles this case correctly in syncBatch (lines 108-117) — "abort instead of throwing to prevent infinite queue retries." This brings the three remaining entry points in line: log + return (or return [] for getContacts), don't throw.
• The throws were surfacing as "Recovery dispatch failed for connection" warns at the api worker level, blocking the parent connector's recovery dispatch from completing.

Why

We hit this on prod tonight while diagnosing why kris@plot.day's Personal Google Calendar wasn't recovering after a stuck-sync repair. PostHog log at 2026-04-28T22:32:28Z revealed the unwrapped __TWIST_ERROR__: "No Google authentication token available" thrown at _GoogleContacts.onChannelEnabled — bubbling up from a recovery dispatch on a parent GCal twist.

The deeper cause behind the missing token is a real model mismatch worth following up on:

GoogleContacts is built as a sub-connector via Integrations.MergeScopes. getChannels() returns a static {id: "contacts"}, so integrations.get("contacts") looks up a token keyed by "contacts" — but the parent's OAuth flow stored tokens keyed by calendar/drive/gmail channel ids. The lookup misses by design even when OAuth is healthy. The right long-term fix is to route sub-connector token lookups through the parent's token store on miss; that's a runtime change in @plotday/twister/api worker and should land separately.

For now, fail-soft restores reliability: contacts won't sync until the next OAuth touchpoint or daily refresh, which is acceptable for the contacts-as-side-effect use case and unblocks the parent connector's recovery for the two affected users (kris@plot.day Personal GCal, cameronandrewpak@gmail.com).

Test plan

• After deploy, re-arm recovery_pending=true on the affected twist_instance_connection rows
• Confirm next 30-min recoverPendingConnections cron reaches the parent GCal connector's onChannelEnabled without surfacing a "Recovery dispatch failed" warn
• Confirm link count starts climbing on 019dac4d-96cc-7c24-9d6c-2a45854cbf42
• Spot-check PostHog logs for the new "Auth token missing for ... during onChannelEnabled, skipping" warn — confirms fail-soft path was taken

🤖 Generated with Claude Code

[KrisBraun]

Summary

• onChannelEnabled, getContacts, startSync in connectors/google-contacts/src/google-contacts.ts all threw "No Google authentication token available" when integrations.get(channelId) returned null. The same connector already handles this case correctly in syncBatch (lines 108-117) — "abort instead of throwing to prevent infinite queue retries." This brings the three remaining entry points in line: log + return (or return [] for getContacts), don't throw.
• The throws were surfacing as "Recovery dispatch failed for connection" warns at the api worker level, blocking the parent connector's recovery dispatch from completing.

Why

We hit this on prod tonight while diagnosing why kris@plot.day's Personal Google Calendar wasn't recovering after a stuck-sync repair. PostHog log at 2026-04-28T22:32:28Z revealed the unwrapped __TWIST_ERROR__: "No Google authentication token available" thrown at _GoogleContacts.onChannelEnabled — bubbling up from a recovery dispatch on a parent GCal twist.

The deeper cause behind the missing token is a real model mismatch worth following up on:

GoogleContacts is built as a sub-connector via Integrations.MergeScopes. getChannels() returns a static {id: "contacts"}, so integrations.get("contacts") looks up a token keyed by "contacts" — but the parent's OAuth flow stored tokens keyed by calendar/drive/gmail channel ids. The lookup misses by design even when OAuth is healthy. The right long-term fix is to route sub-connector token lookups through the parent's token store on miss; that's a runtime change in @plotday/twister/api worker and should land separately.

For now, fail-soft restores reliability: contacts won't sync until the next OAuth touchpoint or daily refresh, which is acceptable for the contacts-as-side-effect use case and unblocks the parent connector's recovery for the two affected users (kris@plot.day Personal GCal, cameronandrewpak@gmail.com).

Test plan

• After deploy, re-arm recovery_pending=true on the affected twist_instance_connection rows
• Confirm next 30-min recoverPendingConnections cron reaches the parent GCal connector's onChannelEnabled without surfacing a "Recovery dispatch failed" warn
• Confirm link count starts climbing on 019dac4d-96cc-7c24-9d6c-2a45854cbf42
• Spot-check PostHog logs for the new "Auth token missing for ... during onChannelEnabled, skipping" warn — confirms fail-soft path was taken

🤖 Generated with Claude Code

[KrisBraun]

Summary

• onChannelEnabled, getContacts, startSync in connectors/google-contacts/src/google-contacts.ts all threw "No Google authentication token available" when integrations.get(channelId) returned null. The same connector already handles this case correctly in syncBatch (lines 108-117) — "abort instead of throwing to prevent infinite queue retries." This brings the three remaining entry points in line: log + return (or return [] for getContacts), don't throw.
• The throws were surfacing as "Recovery dispatch failed for connection" warns at the api worker level, blocking the parent connector's recovery dispatch from completing.

Why

We hit this on prod tonight while diagnosing why kris@plot.day's Personal Google Calendar wasn't recovering after a stuck-sync repair. PostHog log at 2026-04-28T22:32:28Z revealed the unwrapped __TWIST_ERROR__: "No Google authentication token available" thrown at _GoogleContacts.onChannelEnabled — bubbling up from a recovery dispatch on a parent GCal twist.

The deeper cause behind the missing token is a real model mismatch worth following up on:

GoogleContacts is built as a sub-connector via Integrations.MergeScopes. getChannels() returns a static {id: "contacts"}, so integrations.get("contacts") looks up a token keyed by "contacts" — but the parent's OAuth flow stored tokens keyed by calendar/drive/gmail channel ids. The lookup misses by design even when OAuth is healthy. The right long-term fix is to route sub-connector token lookups through the parent's token store on miss; that's a runtime change in @plotday/twister/api worker and should land separately.

For now, fail-soft restores reliability: contacts won't sync until the next OAuth touchpoint or daily refresh, which is acceptable for the contacts-as-side-effect use case and unblocks the parent connector's recovery for the two affected users (kris@plot.day Personal GCal, cameronandrewpak@gmail.com).

Test plan

• After deploy, re-arm recovery_pending=true on the affected twist_instance_connection rows
• Confirm next 30-min recoverPendingConnections cron reaches the parent GCal connector's onChannelEnabled without surfacing a "Recovery dispatch failed" warn
• Confirm link count starts climbing on 019dac4d-96cc-7c24-9d6c-2a45854cbf42
• Spot-check PostHog logs for the new "Auth token missing for ... during onChannelEnabled, skipping" warn — confirms fail-soft path was taken

🤖 Generated with Claude Code

[KrisBraun]

Summary

• onChannelEnabled, getContacts, startSync in connectors/google-contacts/src/google-contacts.ts all threw "No Google authentication token available" when integrations.get(channelId) returned null. The same connector already handles this case correctly in syncBatch (lines 108-117) — "abort instead of throwing to prevent infinite queue retries." This brings the three remaining entry points in line: log + return (or return [] for getContacts), don't throw.
• The throws were surfacing as "Recovery dispatch failed for connection" warns at the api worker level, blocking the parent connector's recovery dispatch from completing.

Why

We hit this on prod tonight while diagnosing why kris@plot.day's Personal Google Calendar wasn't recovering after a stuck-sync repair. PostHog log at 2026-04-28T22:32:28Z revealed the unwrapped __TWIST_ERROR__: "No Google authentication token available" thrown at _GoogleContacts.onChannelEnabled — bubbling up from a recovery dispatch on a parent GCal twist.

The deeper cause behind the missing token is a real model mismatch worth following up on:

GoogleContacts is built as a sub-connector via Integrations.MergeScopes. getChannels() returns a static {id: "contacts"}, so integrations.get("contacts") looks up a token keyed by "contacts" — but the parent's OAuth flow stored tokens keyed by calendar/drive/gmail channel ids. The lookup misses by design even when OAuth is healthy. The right long-term fix is to route sub-connector token lookups through the parent's token store on miss; that's a runtime change in @plotday/twister/api worker and should land separately.

For now, fail-soft restores reliability: contacts won't sync until the next OAuth touchpoint or daily refresh, which is acceptable for the contacts-as-side-effect use case and unblocks the parent connector's recovery for the two affected users (kris@plot.day Personal GCal, cameronandrewpak@gmail.com).

Test plan

• After deploy, re-arm recovery_pending=true on the affected twist_instance_connection rows
• Confirm next 30-min recoverPendingConnections cron reaches the parent GCal connector's onChannelEnabled without surfacing a "Recovery dispatch failed" warn
• Confirm link count starts climbing on 019dac4d-96cc-7c24-9d6c-2a45854cbf42
• Spot-check PostHog logs for the new "Auth token missing for ... during onChannelEnabled, skipping" warn — confirms fail-soft path was taken

🤖 Generated with Claude Code

[KrisBraun]

Summary

• onChannelEnabled, getContacts, startSync in connectors/google-contacts/src/google-contacts.ts all threw "No Google authentication token available" when integrations.get(channelId) returned null. The same connector already handles this case correctly in syncBatch (lines 108-117) — "abort instead of throwing to prevent infinite queue retries." This brings the three remaining entry points in line: log + return (or return [] for getContacts), don't throw.
• The throws were surfacing as "Recovery dispatch failed for connection" warns at the api worker level, blocking the parent connector's recovery dispatch from completing.

Why

We hit this on prod tonight while diagnosing why kris@plot.day's Personal Google Calendar wasn't recovering after a stuck-sync repair. PostHog log at 2026-04-28T22:32:28Z revealed the unwrapped __TWIST_ERROR__: "No Google authentication token available" thrown at _GoogleContacts.onChannelEnabled — bubbling up from a recovery dispatch on a parent GCal twist.

The deeper cause behind the missing token is a real model mismatch worth following up on:

GoogleContacts is built as a sub-connector via Integrations.MergeScopes. getChannels() returns a static {id: "contacts"}, so integrations.get("contacts") looks up a token keyed by "contacts" — but the parent's OAuth flow stored tokens keyed by calendar/drive/gmail channel ids. The lookup misses by design even when OAuth is healthy. The right long-term fix is to route sub-connector token lookups through the parent's token store on miss; that's a runtime change in @plotday/twister/api worker and should land separately.

For now, fail-soft restores reliability: contacts won't sync until the next OAuth touchpoint or daily refresh, which is acceptable for the contacts-as-side-effect use case and unblocks the parent connector's recovery for the two affected users (kris@plot.day Personal GCal, cameronandrewpak@gmail.com).

Test plan

• After deploy, re-arm recovery_pending=true on the affected twist_instance_connection rows
• Confirm next 30-min recoverPendingConnections cron reaches the parent GCal connector's onChannelEnabled without surfacing a "Recovery dispatch failed" warn
• Confirm link count starts climbing on 019dac4d-96cc-7c24-9d6c-2a45854cbf42
• Spot-check PostHog logs for the new "Auth token missing for ... during onChannelEnabled, skipping" warn — confirms fail-soft path was taken

🤖 Generated with Claude Code

[KrisBraun]

Summary

• onChannelEnabled, getContacts, startSync in connectors/google-contacts/src/google-contacts.ts all threw "No Google authentication token available" when integrations.get(channelId) returned null. The same connector already handles this case correctly in syncBatch (lines 108-117) — "abort instead of throwing to prevent infinite queue retries." This brings the three remaining entry points in line: log + return (or return [] for getContacts), don't throw.
• The throws were surfacing as "Recovery dispatch failed for connection" warns at the api worker level, blocking the parent connector's recovery dispatch from completing.

Why

We hit this on prod tonight while diagnosing why kris@plot.day's Personal Google Calendar wasn't recovering after a stuck-sync repair. PostHog log at 2026-04-28T22:32:28Z revealed the unwrapped __TWIST_ERROR__: "No Google authentication token available" thrown at _GoogleContacts.onChannelEnabled — bubbling up from a recovery dispatch on a parent GCal twist.

The deeper cause behind the missing token is a real model mismatch worth following up on:

GoogleContacts is built as a sub-connector via Integrations.MergeScopes. getChannels() returns a static {id: "contacts"}, so integrations.get("contacts") looks up a token keyed by "contacts" — but the parent's OAuth flow stored tokens keyed by calendar/drive/gmail channel ids. The lookup misses by design even when OAuth is healthy. The right long-term fix is to route sub-connector token lookups through the parent's token store on miss; that's a runtime change in @plotday/twister/api worker and should land separately.

For now, fail-soft restores reliability: contacts won't sync until the next OAuth touchpoint or daily refresh, which is acceptable for the contacts-as-side-effect use case and unblocks the parent connector's recovery for the two affected users (kris@plot.day Personal GCal, cameronandrewpak@gmail.com).

Test plan

• After deploy, re-arm recovery_pending=true on the affected twist_instance_connection rows
• Confirm next 30-min recoverPendingConnections cron reaches the parent GCal connector's onChannelEnabled without surfacing a "Recovery dispatch failed" warn
• Confirm link count starts climbing on 019dac4d-96cc-7c24-9d6c-2a45854cbf42
• Spot-check PostHog logs for the new "Auth token missing for ... during onChannelEnabled, skipping" warn — confirms fail-soft path was taken

🤖 Generated with Claude Code