fix(calendar): skip cancellations for events fully in the past

[KrisBraun]

Problem

A cancelled calendar event that has already ended would still surface a "cancelled" note and flip the thread unread when the cancellation synced in. Observed in prod (thread): a recurring occurrence (May 1) was cancelled and synced ~2 months later, flipping an Untitled thread (no info about the original event) to unread — pure noise.

This is a sibling of #238 (which dropped cancellations of never-imported events). That guard didn't catch this case because the occurrence was within the 2-year history window and event.updated was recent.

Fix

New cancellationIsForPastEventFn guard, applied after the existing never-imported guard, in every cancellation path that carries event time:

• google-calendar: standalone (processCalendarEventsFn) + recurring-occurrence (prepareEventInstanceFn) cancellation paths — both create cancellation notes.
• apple-calendar: standalone (prepareEvent) + recurring-occurrence (prepareEventInstance) paths.
• outlook-calendar: recurring-occurrence path (prepareEventInstanceFn); best-effort on the delta-removed (@removed) path — Microsoft Graph returns removed items with only an id, so time data is usually absent and the event is kept (the only Outlook path that creates a cancellation note; it can't be reliably guarded by event time).

The "end" is the event's explicit end when present (all-day end is the exclusive next-day boundary), else its start (all-day starts run to end of day; for occurrences, originalStart). Events that have started but not finished (ongoing) and future events are kept, so the user still learns an upcoming/in-progress meeting won't happen.

The composite google and outlook connectors inherit the fix through the shared sync functions.

Tests

• google-calendar: 5 new tests (past / ongoing / future / all-day-today / prod-scenario occurrence) + 2 existing "keep" tests made date-robust. 48/48 green.
• apple-calendar: new vitest setup + 7 helper tests. 7/7 green.
• outlook-calendar: new vitest setup + 6 helper tests (incl. @removed no-time → kept). 6/6 green.

tsc --noEmit clean for all three. Connector-only → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

A cancelled calendar event that has already ended would still surface a "cancelled" note and flip the thread unread when the cancellation synced in. Observed in prod (thread): a recurring occurrence (May 1) was cancelled and synced ~2 months later, flipping an Untitled thread (no info about the original event) to unread — pure noise.

This is a sibling of #238 (which dropped cancellations of never-imported events). That guard didn't catch this case because the occurrence was within the 2-year history window and event.updated was recent.

Fix

New cancellationIsForPastEventFn guard, applied after the existing never-imported guard, in every cancellation path that carries event time:

• google-calendar: standalone (processCalendarEventsFn) + recurring-occurrence (prepareEventInstanceFn) cancellation paths — both create cancellation notes.
• apple-calendar: standalone (prepareEvent) + recurring-occurrence (prepareEventInstance) paths.
• outlook-calendar: recurring-occurrence path (prepareEventInstanceFn); best-effort on the delta-removed (@removed) path — Microsoft Graph returns removed items with only an id, so time data is usually absent and the event is kept (the only Outlook path that creates a cancellation note; it can't be reliably guarded by event time).

The "end" is the event's explicit end when present (all-day end is the exclusive next-day boundary), else its start (all-day starts run to end of day; for occurrences, originalStart). Events that have started but not finished (ongoing) and future events are kept, so the user still learns an upcoming/in-progress meeting won't happen.

The composite google and outlook connectors inherit the fix through the shared sync functions.

Tests

• google-calendar: 5 new tests (past / ongoing / future / all-day-today / prod-scenario occurrence) + 2 existing "keep" tests made date-robust. 48/48 green.
• apple-calendar: new vitest setup + 7 helper tests. 7/7 green.
• outlook-calendar: new vitest setup + 6 helper tests (incl. @removed no-time → kept). 6/6 green.

tsc --noEmit clean for all three. Connector-only → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

A cancelled calendar event that has already ended would still surface a "cancelled" note and flip the thread unread when the cancellation synced in. Observed in prod (thread): a recurring occurrence (May 1) was cancelled and synced ~2 months later, flipping an Untitled thread (no info about the original event) to unread — pure noise.

This is a sibling of #238 (which dropped cancellations of never-imported events). That guard didn't catch this case because the occurrence was within the 2-year history window and event.updated was recent.

Fix

New cancellationIsForPastEventFn guard, applied after the existing never-imported guard, in every cancellation path that carries event time:

• google-calendar: standalone (processCalendarEventsFn) + recurring-occurrence (prepareEventInstanceFn) cancellation paths — both create cancellation notes.
• apple-calendar: standalone (prepareEvent) + recurring-occurrence (prepareEventInstance) paths.
• outlook-calendar: recurring-occurrence path (prepareEventInstanceFn); best-effort on the delta-removed (@removed) path — Microsoft Graph returns removed items with only an id, so time data is usually absent and the event is kept (the only Outlook path that creates a cancellation note; it can't be reliably guarded by event time).

The "end" is the event's explicit end when present (all-day end is the exclusive next-day boundary), else its start (all-day starts run to end of day; for occurrences, originalStart). Events that have started but not finished (ongoing) and future events are kept, so the user still learns an upcoming/in-progress meeting won't happen.

The composite google and outlook connectors inherit the fix through the shared sync functions.

Tests

• google-calendar: 5 new tests (past / ongoing / future / all-day-today / prod-scenario occurrence) + 2 existing "keep" tests made date-robust. 48/48 green.
• apple-calendar: new vitest setup + 7 helper tests. 7/7 green.
• outlook-calendar: new vitest setup + 6 helper tests (incl. @removed no-time → kept). 6/6 green.

tsc --noEmit clean for all three. Connector-only → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

A cancelled calendar event that has already ended would still surface a "cancelled" note and flip the thread unread when the cancellation synced in. Observed in prod (thread): a recurring occurrence (May 1) was cancelled and synced ~2 months later, flipping an Untitled thread (no info about the original event) to unread — pure noise.

This is a sibling of #238 (which dropped cancellations of never-imported events). That guard didn't catch this case because the occurrence was within the 2-year history window and event.updated was recent.

Fix

New cancellationIsForPastEventFn guard, applied after the existing never-imported guard, in every cancellation path that carries event time:

• google-calendar: standalone (processCalendarEventsFn) + recurring-occurrence (prepareEventInstanceFn) cancellation paths — both create cancellation notes.
• apple-calendar: standalone (prepareEvent) + recurring-occurrence (prepareEventInstance) paths.
• outlook-calendar: recurring-occurrence path (prepareEventInstanceFn); best-effort on the delta-removed (@removed) path — Microsoft Graph returns removed items with only an id, so time data is usually absent and the event is kept (the only Outlook path that creates a cancellation note; it can't be reliably guarded by event time).

The "end" is the event's explicit end when present (all-day end is the exclusive next-day boundary), else its start (all-day starts run to end of day; for occurrences, originalStart). Events that have started but not finished (ongoing) and future events are kept, so the user still learns an upcoming/in-progress meeting won't happen.

The composite google and outlook connectors inherit the fix through the shared sync functions.

Tests

• google-calendar: 5 new tests (past / ongoing / future / all-day-today / prod-scenario occurrence) + 2 existing "keep" tests made date-robust. 48/48 green.
• apple-calendar: new vitest setup + 7 helper tests. 7/7 green.
• outlook-calendar: new vitest setup + 6 helper tests (incl. @removed no-time → kept). 6/6 green.

tsc --noEmit clean for all three. Connector-only → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

A cancelled calendar event that has already ended would still surface a "cancelled" note and flip the thread unread when the cancellation synced in. Observed in prod (thread): a recurring occurrence (May 1) was cancelled and synced ~2 months later, flipping an Untitled thread (no info about the original event) to unread — pure noise.

This is a sibling of #238 (which dropped cancellations of never-imported events). That guard didn't catch this case because the occurrence was within the 2-year history window and event.updated was recent.

Fix

New cancellationIsForPastEventFn guard, applied after the existing never-imported guard, in every cancellation path that carries event time:

• google-calendar: standalone (processCalendarEventsFn) + recurring-occurrence (prepareEventInstanceFn) cancellation paths — both create cancellation notes.
• apple-calendar: standalone (prepareEvent) + recurring-occurrence (prepareEventInstance) paths.
• outlook-calendar: recurring-occurrence path (prepareEventInstanceFn); best-effort on the delta-removed (@removed) path — Microsoft Graph returns removed items with only an id, so time data is usually absent and the event is kept (the only Outlook path that creates a cancellation note; it can't be reliably guarded by event time).

The "end" is the event's explicit end when present (all-day end is the exclusive next-day boundary), else its start (all-day starts run to end of day; for occurrences, originalStart). Events that have started but not finished (ongoing) and future events are kept, so the user still learns an upcoming/in-progress meeting won't happen.

The composite google and outlook connectors inherit the fix through the shared sync functions.

Tests

• google-calendar: 5 new tests (past / ongoing / future / all-day-today / prod-scenario occurrence) + 2 existing "keep" tests made date-robust. 48/48 green.
• apple-calendar: new vitest setup + 7 helper tests. 7/7 green.
• outlook-calendar: new vitest setup + 6 helper tests (incl. @removed no-time → kept). 6/6 green.

tsc --noEmit clean for all three. Connector-only → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

A cancelled calendar event that has already ended would still surface a "cancelled" note and flip the thread unread when the cancellation synced in. Observed in prod (thread): a recurring occurrence (May 1) was cancelled and synced ~2 months later, flipping an Untitled thread (no info about the original event) to unread — pure noise.

This is a sibling of #238 (which dropped cancellations of never-imported events). That guard didn't catch this case because the occurrence was within the 2-year history window and event.updated was recent.

Fix

New cancellationIsForPastEventFn guard, applied after the existing never-imported guard, in every cancellation path that carries event time:

• google-calendar: standalone (processCalendarEventsFn) + recurring-occurrence (prepareEventInstanceFn) cancellation paths — both create cancellation notes.
• apple-calendar: standalone (prepareEvent) + recurring-occurrence (prepareEventInstance) paths.
• outlook-calendar: recurring-occurrence path (prepareEventInstanceFn); best-effort on the delta-removed (@removed) path — Microsoft Graph returns removed items with only an id, so time data is usually absent and the event is kept (the only Outlook path that creates a cancellation note; it can't be reliably guarded by event time).

The "end" is the event's explicit end when present (all-day end is the exclusive next-day boundary), else its start (all-day starts run to end of day; for occurrences, originalStart). Events that have started but not finished (ongoing) and future events are kept, so the user still learns an upcoming/in-progress meeting won't happen.

The composite google and outlook connectors inherit the fix through the shared sync functions.

Tests

• google-calendar: 5 new tests (past / ongoing / future / all-day-today / prod-scenario occurrence) + 2 existing "keep" tests made date-robust. 48/48 green.
• apple-calendar: new vitest setup + 7 helper tests. 7/7 green.
• outlook-calendar: new vitest setup + 6 helper tests (incl. @removed no-time → kept). 6/6 green.

tsc --noEmit clean for all three. Connector-only → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

A cancelled calendar event that has already ended would still surface a "cancelled" note and flip the thread unread when the cancellation synced in. Observed in prod (thread): a recurring occurrence (May 1) was cancelled and synced ~2 months later, flipping an Untitled thread (no info about the original event) to unread — pure noise.

This is a sibling of #238 (which dropped cancellations of never-imported events). That guard didn't catch this case because the occurrence was within the 2-year history window and event.updated was recent.

Fix

New cancellationIsForPastEventFn guard, applied after the existing never-imported guard, in every cancellation path that carries event time:

• google-calendar: standalone (processCalendarEventsFn) + recurring-occurrence (prepareEventInstanceFn) cancellation paths — both create cancellation notes.
• apple-calendar: standalone (prepareEvent) + recurring-occurrence (prepareEventInstance) paths.
• outlook-calendar: recurring-occurrence path (prepareEventInstanceFn); best-effort on the delta-removed (@removed) path — Microsoft Graph returns removed items with only an id, so time data is usually absent and the event is kept (the only Outlook path that creates a cancellation note; it can't be reliably guarded by event time).

The "end" is the event's explicit end when present (all-day end is the exclusive next-day boundary), else its start (all-day starts run to end of day; for occurrences, originalStart). Events that have started but not finished (ongoing) and future events are kept, so the user still learns an upcoming/in-progress meeting won't happen.

The composite google and outlook connectors inherit the fix through the shared sync functions.

Tests

• google-calendar: 5 new tests (past / ongoing / future / all-day-today / prod-scenario occurrence) + 2 existing "keep" tests made date-robust. 48/48 green.
• apple-calendar: new vitest setup + 7 helper tests. 7/7 green.
• outlook-calendar: new vitest setup + 6 helper tests (incl. @removed no-time → kept). 6/6 green.

tsc --noEmit clean for all three. Connector-only → no changeset.

🤖 Generated with Claude Code

[KrisBraun]

Problem

A cancelled calendar event that has already ended would still surface a "cancelled" note and flip the thread unread when the cancellation synced in. Observed in prod (thread): a recurring occurrence (May 1) was cancelled and synced ~2 months later, flipping an Untitled thread (no info about the original event) to unread — pure noise.

This is a sibling of #238 (which dropped cancellations of never-imported events). That guard didn't catch this case because the occurrence was within the 2-year history window and event.updated was recent.

Fix

New cancellationIsForPastEventFn guard, applied after the existing never-imported guard, in every cancellation path that carries event time:

• google-calendar: standalone (processCalendarEventsFn) + recurring-occurrence (prepareEventInstanceFn) cancellation paths — both create cancellation notes.
• apple-calendar: standalone (prepareEvent) + recurring-occurrence (prepareEventInstance) paths.
• outlook-calendar: recurring-occurrence path (prepareEventInstanceFn); best-effort on the delta-removed (@removed) path — Microsoft Graph returns removed items with only an id, so time data is usually absent and the event is kept (the only Outlook path that creates a cancellation note; it can't be reliably guarded by event time).

The "end" is the event's explicit end when present (all-day end is the exclusive next-day boundary), else its start (all-day starts run to end of day; for occurrences, originalStart). Events that have started but not finished (ongoing) and future events are kept, so the user still learns an upcoming/in-progress meeting won't happen.

The composite google and outlook connectors inherit the fix through the shared sync functions.

Tests

• google-calendar: 5 new tests (past / ongoing / future / all-day-today / prod-scenario occurrence) + 2 existing "keep" tests made date-robust. 48/48 green.
• apple-calendar: new vitest setup + 7 helper tests. 7/7 green.
• outlook-calendar: new vitest setup + 6 helper tests (incl. @removed no-time → kept). 6/6 green.

tsc --noEmit clean for all three. Connector-only → no changeset.

🤖 Generated with Claude Code