fix(google-calendar): drop cancellations of never-imported events

[KrisBraun]

Problem

In prod, a 3-year-old calendar event ("Product 0️⃣➡️1️⃣") suddenly appeared as unread, despite not having changed in years.

Root cause, traced in the prod DB:

1. The Google composite-connector cutover archived the standalone "Google Calendar" twist and started a fresh sync under the new "Gmail & Calendar" twist.
2. The calendar initial backfill imports a bounded window (history floor = Jan 1 of two years ago → future) and deliberately skips already-cancelled events. The 2023 event was both cancelled and before the floor, so it was never imported.
3. A later incremental sync (syncToken + showDeleted: true) surfaced that old cancelled recurring master — a Google quirk where the sync token leaks cancellations from outside the initial timeMin window.
4. The cancellation handler called saveLink. Thread dedup is keyed on (twist_id, key), and the new twist had no matching thread, so saveLinkcreated a brand-new thread with a "This event was cancelled." note. Incremental syncs don't set unread: false, so it landed unread — a phantom for an event the user never saw in Plot.

Fix

Guard both incremental cancellation paths (processCalendarEventsFn whole-event and prepareEventInstanceFn occurrence) with a new cancellationIsForUnimportedEventFn, which drops a cancellation when the event was never imported — detected by either:

• event.updated predates when we first synced this calendar (new set-once first_sync_at_<calendarId> marker written in runCalendarInit) — it was already cancelled at backfill time, so we skipped it; or
• the event's scheduled time is older than the import history floor (stateless fallback for connector instances initialised before the marker existed).

Real cancellations of imported, upcoming events satisfy neither signal and still surface as unread (e.g. a meeting tomorrow getting cancelled). Also de-duplicated the history-floor computation into calendarHistoryFloor().

This guard lives in the shared google-calendar sync code, so it covers both the standalone Google Calendar connector and the composite Gmail & Calendar connector.

Testing

• TDD: 5 new tests (the 3 "drop" cases failed first, RED).
• pnpm exec vitest run → 43/43 green.
• tsc --noEmit and plot lint clean (for both google-calendar and the composite google connector).

No changeset (connector-only change). Forward-only — does not backfill the one existing phantom thread already in prod (archive it manually).

🤖 Generated with Claude Code

[KrisBraun]

Problem

In prod, a 3-year-old calendar event ("Product 0️⃣➡️1️⃣") suddenly appeared as unread, despite not having changed in years.

Root cause, traced in the prod DB:

1. The Google composite-connector cutover archived the standalone "Google Calendar" twist and started a fresh sync under the new "Gmail & Calendar" twist.
2. The calendar initial backfill imports a bounded window (history floor = Jan 1 of two years ago → future) and deliberately skips already-cancelled events. The 2023 event was both cancelled and before the floor, so it was never imported.
3. A later incremental sync (syncToken + showDeleted: true) surfaced that old cancelled recurring master — a Google quirk where the sync token leaks cancellations from outside the initial timeMin window.
4. The cancellation handler called saveLink. Thread dedup is keyed on (twist_id, key), and the new twist had no matching thread, so saveLinkcreated a brand-new thread with a "This event was cancelled." note. Incremental syncs don't set unread: false, so it landed unread — a phantom for an event the user never saw in Plot.

Fix

Guard both incremental cancellation paths (processCalendarEventsFn whole-event and prepareEventInstanceFn occurrence) with a new cancellationIsForUnimportedEventFn, which drops a cancellation when the event was never imported — detected by either:

• event.updated predates when we first synced this calendar (new set-once first_sync_at_<calendarId> marker written in runCalendarInit) — it was already cancelled at backfill time, so we skipped it; or
• the event's scheduled time is older than the import history floor (stateless fallback for connector instances initialised before the marker existed).

Real cancellations of imported, upcoming events satisfy neither signal and still surface as unread (e.g. a meeting tomorrow getting cancelled). Also de-duplicated the history-floor computation into calendarHistoryFloor().

This guard lives in the shared google-calendar sync code, so it covers both the standalone Google Calendar connector and the composite Gmail & Calendar connector.

Testing

• TDD: 5 new tests (the 3 "drop" cases failed first, RED).
• pnpm exec vitest run → 43/43 green.
• tsc --noEmit and plot lint clean (for both google-calendar and the composite google connector).

No changeset (connector-only change). Forward-only — does not backfill the one existing phantom thread already in prod (archive it manually).

🤖 Generated with Claude Code

[KrisBraun]

Problem

In prod, a 3-year-old calendar event ("Product 0️⃣➡️1️⃣") suddenly appeared as unread, despite not having changed in years.

Root cause, traced in the prod DB:

1. The Google composite-connector cutover archived the standalone "Google Calendar" twist and started a fresh sync under the new "Gmail & Calendar" twist.
2. The calendar initial backfill imports a bounded window (history floor = Jan 1 of two years ago → future) and deliberately skips already-cancelled events. The 2023 event was both cancelled and before the floor, so it was never imported.
3. A later incremental sync (syncToken + showDeleted: true) surfaced that old cancelled recurring master — a Google quirk where the sync token leaks cancellations from outside the initial timeMin window.
4. The cancellation handler called saveLink. Thread dedup is keyed on (twist_id, key), and the new twist had no matching thread, so saveLinkcreated a brand-new thread with a "This event was cancelled." note. Incremental syncs don't set unread: false, so it landed unread — a phantom for an event the user never saw in Plot.

Fix

Guard both incremental cancellation paths (processCalendarEventsFn whole-event and prepareEventInstanceFn occurrence) with a new cancellationIsForUnimportedEventFn, which drops a cancellation when the event was never imported — detected by either:

• event.updated predates when we first synced this calendar (new set-once first_sync_at_<calendarId> marker written in runCalendarInit) — it was already cancelled at backfill time, so we skipped it; or
• the event's scheduled time is older than the import history floor (stateless fallback for connector instances initialised before the marker existed).

Real cancellations of imported, upcoming events satisfy neither signal and still surface as unread (e.g. a meeting tomorrow getting cancelled). Also de-duplicated the history-floor computation into calendarHistoryFloor().

This guard lives in the shared google-calendar sync code, so it covers both the standalone Google Calendar connector and the composite Gmail & Calendar connector.

Testing

• TDD: 5 new tests (the 3 "drop" cases failed first, RED).
• pnpm exec vitest run → 43/43 green.
• tsc --noEmit and plot lint clean (for both google-calendar and the composite google connector).

No changeset (connector-only change). Forward-only — does not backfill the one existing phantom thread already in prod (archive it manually).

🤖 Generated with Claude Code

[KrisBraun]

Problem

In prod, a 3-year-old calendar event ("Product 0️⃣➡️1️⃣") suddenly appeared as unread, despite not having changed in years.

Root cause, traced in the prod DB:

1. The Google composite-connector cutover archived the standalone "Google Calendar" twist and started a fresh sync under the new "Gmail & Calendar" twist.
2. The calendar initial backfill imports a bounded window (history floor = Jan 1 of two years ago → future) and deliberately skips already-cancelled events. The 2023 event was both cancelled and before the floor, so it was never imported.
3. A later incremental sync (syncToken + showDeleted: true) surfaced that old cancelled recurring master — a Google quirk where the sync token leaks cancellations from outside the initial timeMin window.
4. The cancellation handler called saveLink. Thread dedup is keyed on (twist_id, key), and the new twist had no matching thread, so saveLinkcreated a brand-new thread with a "This event was cancelled." note. Incremental syncs don't set unread: false, so it landed unread — a phantom for an event the user never saw in Plot.

Fix

Guard both incremental cancellation paths (processCalendarEventsFn whole-event and prepareEventInstanceFn occurrence) with a new cancellationIsForUnimportedEventFn, which drops a cancellation when the event was never imported — detected by either:

• event.updated predates when we first synced this calendar (new set-once first_sync_at_<calendarId> marker written in runCalendarInit) — it was already cancelled at backfill time, so we skipped it; or
• the event's scheduled time is older than the import history floor (stateless fallback for connector instances initialised before the marker existed).

Real cancellations of imported, upcoming events satisfy neither signal and still surface as unread (e.g. a meeting tomorrow getting cancelled). Also de-duplicated the history-floor computation into calendarHistoryFloor().

This guard lives in the shared google-calendar sync code, so it covers both the standalone Google Calendar connector and the composite Gmail & Calendar connector.

Testing

• TDD: 5 new tests (the 3 "drop" cases failed first, RED).
• pnpm exec vitest run → 43/43 green.
• tsc --noEmit and plot lint clean (for both google-calendar and the composite google connector).

No changeset (connector-only change). Forward-only — does not backfill the one existing phantom thread already in prod (archive it manually).

🤖 Generated with Claude Code

[KrisBraun]

Problem

In prod, a 3-year-old calendar event ("Product 0️⃣➡️1️⃣") suddenly appeared as unread, despite not having changed in years.

Root cause, traced in the prod DB:

1. The Google composite-connector cutover archived the standalone "Google Calendar" twist and started a fresh sync under the new "Gmail & Calendar" twist.
2. The calendar initial backfill imports a bounded window (history floor = Jan 1 of two years ago → future) and deliberately skips already-cancelled events. The 2023 event was both cancelled and before the floor, so it was never imported.
3. A later incremental sync (syncToken + showDeleted: true) surfaced that old cancelled recurring master — a Google quirk where the sync token leaks cancellations from outside the initial timeMin window.
4. The cancellation handler called saveLink. Thread dedup is keyed on (twist_id, key), and the new twist had no matching thread, so saveLinkcreated a brand-new thread with a "This event was cancelled." note. Incremental syncs don't set unread: false, so it landed unread — a phantom for an event the user never saw in Plot.

Fix

Guard both incremental cancellation paths (processCalendarEventsFn whole-event and prepareEventInstanceFn occurrence) with a new cancellationIsForUnimportedEventFn, which drops a cancellation when the event was never imported — detected by either:

• event.updated predates when we first synced this calendar (new set-once first_sync_at_<calendarId> marker written in runCalendarInit) — it was already cancelled at backfill time, so we skipped it; or
• the event's scheduled time is older than the import history floor (stateless fallback for connector instances initialised before the marker existed).

Real cancellations of imported, upcoming events satisfy neither signal and still surface as unread (e.g. a meeting tomorrow getting cancelled). Also de-duplicated the history-floor computation into calendarHistoryFloor().

This guard lives in the shared google-calendar sync code, so it covers both the standalone Google Calendar connector and the composite Gmail & Calendar connector.

Testing

• TDD: 5 new tests (the 3 "drop" cases failed first, RED).
• pnpm exec vitest run → 43/43 green.
• tsc --noEmit and plot lint clean (for both google-calendar and the composite google connector).

No changeset (connector-only change). Forward-only — does not backfill the one existing phantom thread already in prod (archive it manually).

🤖 Generated with Claude Code

[KrisBraun]

Problem

In prod, a 3-year-old calendar event ("Product 0️⃣➡️1️⃣") suddenly appeared as unread, despite not having changed in years.

Root cause, traced in the prod DB:

1. The Google composite-connector cutover archived the standalone "Google Calendar" twist and started a fresh sync under the new "Gmail & Calendar" twist.
2. The calendar initial backfill imports a bounded window (history floor = Jan 1 of two years ago → future) and deliberately skips already-cancelled events. The 2023 event was both cancelled and before the floor, so it was never imported.
3. A later incremental sync (syncToken + showDeleted: true) surfaced that old cancelled recurring master — a Google quirk where the sync token leaks cancellations from outside the initial timeMin window.
4. The cancellation handler called saveLink. Thread dedup is keyed on (twist_id, key), and the new twist had no matching thread, so saveLinkcreated a brand-new thread with a "This event was cancelled." note. Incremental syncs don't set unread: false, so it landed unread — a phantom for an event the user never saw in Plot.

Fix

Guard both incremental cancellation paths (processCalendarEventsFn whole-event and prepareEventInstanceFn occurrence) with a new cancellationIsForUnimportedEventFn, which drops a cancellation when the event was never imported — detected by either:

• event.updated predates when we first synced this calendar (new set-once first_sync_at_<calendarId> marker written in runCalendarInit) — it was already cancelled at backfill time, so we skipped it; or
• the event's scheduled time is older than the import history floor (stateless fallback for connector instances initialised before the marker existed).

Real cancellations of imported, upcoming events satisfy neither signal and still surface as unread (e.g. a meeting tomorrow getting cancelled). Also de-duplicated the history-floor computation into calendarHistoryFloor().

This guard lives in the shared google-calendar sync code, so it covers both the standalone Google Calendar connector and the composite Gmail & Calendar connector.

Testing

• TDD: 5 new tests (the 3 "drop" cases failed first, RED).
• pnpm exec vitest run → 43/43 green.
• tsc --noEmit and plot lint clean (for both google-calendar and the composite google connector).

No changeset (connector-only change). Forward-only — does not backfill the one existing phantom thread already in prod (archive it manually).

🤖 Generated with Claude Code

[KrisBraun]

Problem

In prod, a 3-year-old calendar event ("Product 0️⃣➡️1️⃣") suddenly appeared as unread, despite not having changed in years.

Root cause, traced in the prod DB:

1. The Google composite-connector cutover archived the standalone "Google Calendar" twist and started a fresh sync under the new "Gmail & Calendar" twist.
2. The calendar initial backfill imports a bounded window (history floor = Jan 1 of two years ago → future) and deliberately skips already-cancelled events. The 2023 event was both cancelled and before the floor, so it was never imported.
3. A later incremental sync (syncToken + showDeleted: true) surfaced that old cancelled recurring master — a Google quirk where the sync token leaks cancellations from outside the initial timeMin window.
4. The cancellation handler called saveLink. Thread dedup is keyed on (twist_id, key), and the new twist had no matching thread, so saveLinkcreated a brand-new thread with a "This event was cancelled." note. Incremental syncs don't set unread: false, so it landed unread — a phantom for an event the user never saw in Plot.

Fix

Guard both incremental cancellation paths (processCalendarEventsFn whole-event and prepareEventInstanceFn occurrence) with a new cancellationIsForUnimportedEventFn, which drops a cancellation when the event was never imported — detected by either:

• event.updated predates when we first synced this calendar (new set-once first_sync_at_<calendarId> marker written in runCalendarInit) — it was already cancelled at backfill time, so we skipped it; or
• the event's scheduled time is older than the import history floor (stateless fallback for connector instances initialised before the marker existed).

Real cancellations of imported, upcoming events satisfy neither signal and still surface as unread (e.g. a meeting tomorrow getting cancelled). Also de-duplicated the history-floor computation into calendarHistoryFloor().

This guard lives in the shared google-calendar sync code, so it covers both the standalone Google Calendar connector and the composite Gmail & Calendar connector.

Testing

• TDD: 5 new tests (the 3 "drop" cases failed first, RED).
• pnpm exec vitest run → 43/43 green.
• tsc --noEmit and plot lint clean (for both google-calendar and the composite google connector).

No changeset (connector-only change). Forward-only — does not backfill the one existing phantom thread already in prod (archive it manually).

🤖 Generated with Claude Code

[KrisBraun]

Problem

In prod, a 3-year-old calendar event ("Product 0️⃣➡️1️⃣") suddenly appeared as unread, despite not having changed in years.

Root cause, traced in the prod DB:

1. The Google composite-connector cutover archived the standalone "Google Calendar" twist and started a fresh sync under the new "Gmail & Calendar" twist.
2. The calendar initial backfill imports a bounded window (history floor = Jan 1 of two years ago → future) and deliberately skips already-cancelled events. The 2023 event was both cancelled and before the floor, so it was never imported.
3. A later incremental sync (syncToken + showDeleted: true) surfaced that old cancelled recurring master — a Google quirk where the sync token leaks cancellations from outside the initial timeMin window.
4. The cancellation handler called saveLink. Thread dedup is keyed on (twist_id, key), and the new twist had no matching thread, so saveLinkcreated a brand-new thread with a "This event was cancelled." note. Incremental syncs don't set unread: false, so it landed unread — a phantom for an event the user never saw in Plot.

Fix

Guard both incremental cancellation paths (processCalendarEventsFn whole-event and prepareEventInstanceFn occurrence) with a new cancellationIsForUnimportedEventFn, which drops a cancellation when the event was never imported — detected by either:

• event.updated predates when we first synced this calendar (new set-once first_sync_at_<calendarId> marker written in runCalendarInit) — it was already cancelled at backfill time, so we skipped it; or
• the event's scheduled time is older than the import history floor (stateless fallback for connector instances initialised before the marker existed).

Real cancellations of imported, upcoming events satisfy neither signal and still surface as unread (e.g. a meeting tomorrow getting cancelled). Also de-duplicated the history-floor computation into calendarHistoryFloor().

This guard lives in the shared google-calendar sync code, so it covers both the standalone Google Calendar connector and the composite Gmail & Calendar connector.

Testing

• TDD: 5 new tests (the 3 "drop" cases failed first, RED).
• pnpm exec vitest run → 43/43 green.
• tsc --noEmit and plot lint clean (for both google-calendar and the composite google connector).

No changeset (connector-only change). Forward-only — does not backfill the one existing phantom thread already in prod (archive it manually).

🤖 Generated with Claude Code