Deleted Google Calendar events keep reappearing / never get cleaned up after a stale sync or reconnect

[alikhan126]

Bug Description

Events deleted in Google Calendar keep showing up in Twenty and never go away on their own. It mainly affects connected accounts that haven't synced in a while (a week or more) or accounts that were reconnected after a pause. The calendar channel's sync status shows ACTIVE / completed with no errors, so nothing in the UI hints at a problem.

Expected behavior

An event deleted on Google's side should eventually be removed from Twenty, even if Twenty's sync was stale or the account was reconnected after a pause.

Technical inputs

Root cause is two compounding bugs in the Google Calendar sync driver (GoogleCalendarGetEventsService / CalendarFetchEventsService):

1. HTTP 410 from Google is silently swallowed. Google Calendar's events.list returns 410 fullSyncRequired when a syncToken has expired or been invalidated - which is exactly what happens after a long sync gap or a disconnect/reconnect. GoogleCalendarGetEventsService.handleError special-cased status === 410 to not throw, so the caller received a fake "successful" empty page ({ calendarEventIds: [], calendarEventIdsToDelete: [], nextSyncCursor: '' }) instead of an error. That's why the sync status shows completed with no errors - the failure is never surfaced, and no deletions are ever applied for that round. (Twenty's Microsoft Calendar driver already maps its own 410 to a SYNC_CURSOR_ERROR that triggers a proper full resync - the Google driver never produced that exception.)

2. A full resync never reconciles deletions either. Once a full sync runs (events.list without a syncToken), Google's response only contains events that currently exist - it does not return a cancelled tombstone for something deleted during the gap. The only place in the pipeline that ever marks an event for deletion is item.status === 'cancelled', which is only ever populated by an incremental sync. So even a full resync that runs correctly never notices that a locally-stored event no longer exists on Google's side, and it stays in Twenty indefinitely.

Verification

I verified both of these directly against a live Google Calendar API surface using Veris - a contract-accurate sandbox for Google Calendar/Google identity - through Veris's veris-proxy, which reroutes the actual googleapis client's real https://www.googleapis.com traffic into the sandbox at the kernel level, so the driver code under test is exercised completely unmodified, with its real production hostnames and code paths:

• Created events, ran an initial full sync, deleted one event, then invalidated the sync token the driver would replay - confirmed Google returns 410 with reason: "fullSyncRequired", exactly as assumed.
• Confirmed an incremental sync (still-valid syncToken) does return the deleted event with status: "cancelled" - the tombstone mechanism the whole pipeline relies on.
• Confirmed a full sync (no syncToken) does not return the deleted event at all, in any form - it's just silently absent.
• Ran the actual unmodified GoogleCalendarGetEventsService class through the sandbox: against the current code it resolves successfully on a 410 instead of throwing (the bug); a fix that maps 410 to the existing SYNC_CURSOR_ERROR exception (matching the Microsoft driver's pattern) makes it throw correctly, and veris-proxy's own receipt confirmed the sandbox genuinely received the traffic.

I'll open a PR shortly with the fix (map 410 to SYNC_CURSOR_ERROR, and reconcile a full sync's results against existing local associations) plus regression tests.

[twenty-eng-sync]

Kind: Probably a real bug. Deleted Google Calendar events can remain in Twenty after an expired sync cursor or full resync.
Severity: MEDIUM — calendar data becomes stale, but the defect is limited to deletion reconciliation after stale syncs or reconnects.
Root-cause hypothesis (high confidence): packages/twenty-server/src/modules/calendar/calendar-event-import-manager/drivers/google-calendar/services/google-calendar-get-events.service.ts suppresses HTTP 410 errors and returns an empty successful result; it also derives deletions only from cancelled items, which full sync responses omit.
Missing information: Twenty version/commit and deployment type are not provided; the technical reproduction is otherwise detailed.

[sonarly]

🟠 Sonarly Analysis — High Severity

Stale Google sync tokens leave deleted events behind

Google Calendar deletions are retained indefinitely when a stored sync token expires. The sync reports success instead of resetting the cursor, and the subsequent full sync does not compare Google’s current events with Twenty’s existing associations.

Root Cause

Deleted Google Calendar events remain because two code paths compound:

1. The proximate fetch failure is swallowed. GoogleCalendarGetEventsService sends the stored calendarChannel.syncCursor as Google’s syncToken and requests deleted entries with showDeleted: true [ref:read:google-calendar-get-events.service.ts]. When Google rejects an expired or invalidated token with HTTP 410 (reason: "fullSyncRequired"), handleError() explicitly does not throw for status 410. The surrounding .catch() then returns a fabricated empty page:

return {
  data: {
    items: [],
    nextSyncToken: undefined,
    nextPageToken: undefined,
  },
};

The service consequently returns fullEvents: true, an empty calendarEvents array, and an empty sync cursor instead of a CalendarEventImportDriverException with SYNC_CURSOR_ERROR [ref:read:google-calendar-get-events.service.ts]. CalendarFetchEventsService treats that response as successful, persists the empty cursor, and proceeds through the normal import/status flow [ref:read:calendar-fetch-events.service.ts]. The error handler already has a dedicated SYNC_CURSOR_ERROR branch that resets the cursor and reschedules a full fetch, but the Google driver never emits that exception [ref:read:calendar-event-import-exception-handler.service.ts]. The Microsoft driver demonstrates the intended 410-to-SYNC_CURSOR_ERROR behavior [ref:read:microsoft-calendar-get-events.service.ts; ref:bash:git-show-5476879f77].

2. The recovery full sync cannot remove missing records. On a full Google fetch, the driver formats only the events returned by Google. CalendarEventsImportService deletes associations only for events that arrive as cancellation tombstones and are recognized by filterEventsAndReturnCancelledEvents() [ref:read:calendar-events-import.service.ts; ref:read:filter-events.util.ts]. An event deleted during the stale-token interval is absent from a full-sync response, so it is never included in cancelledEvents and its existing local association is never deleted. The later ID-first calendar refactor confirms the same model: it deletes only IDs whose incremental response has status === "cancelled" and does not reconcile full-sync results against existing associations [ref:bash:git-show-c6aca3f0ea].

The triggering state is a Google channel with an existing local event association and a stored sync cursor that Google has invalidated after a prolonged sync gap or reconnect. The issue report specifically identifies stale channels of approximately a week or more and reconnects, and reports Google returning 410 fullSyncRequired; it also reports that valid incremental syncs provide cancellation tombstones while full syncs omit deleted events. Under that state, Twenty first converts the 410 into a successful empty import, then performs a full sync that sees only currently existing Google events. The deleted local event therefore survives indefinitely while the channel continues to show ACTIVE.

The swallowed-410 behavior was introduced in c8a889995fa56ecbbea858d2f19efdda88b891f4, where the prior cursor-reset handling was refactored into centralized error handling but status 410 remained intentionally non-throwing [ref:bash:git-blame-google-calendar; ref:bash:git-show-c8a889995fa]. The full-sync/no-reconciliation behavior originates in the calendar sync refactor at f4583223032fc355848fee9b5f56ef1d89f0d6a3 [ref:bash:git-show-f458322303]. No evidence indicates a recent deployment introduced the defect; the triggering production state is the invalidated Google cursor combined with a deletion that occurred during the gap.

Blame commit: c8a88999 by bosiraphael — Add error handling service for calendar import (#6203)

Suggested Fix

Updated Google Calendar error handling so HTTP 410 responses map to SYNC_CURSOR_ERROR and reach the existing cursor-reset/rescheduling handler instead of being swallowed.

Added an explicit full-sync indicator for Google fetches. During a Google full sync, the import service now removes channel event associations whose external IDs are absent from the provider response, while preserving existing incremental-sync and CalDAV behavior. Added coverage for 410 parsing and full-sync association reconciliation.

---

Analyzed by Sonarly · View full analysis

[BOHEUS]

I'd say it's expected given that the point of CRM is to keep data even after they're removed from the source they originally were synced but product team should decide first