91455fac39
New articles: - pihole-doh-dot-bypass-defense - pihole-v6-adlist-management - mastodon-db-maintenance - mastodon-federation - fantastical-google-phantom-calendar-syncselect - rsync-tailscale-teardown-stall - ollama-chat-template-pipe-stdin-bypass Updated: wsl2-backup, wsl2-rebuild, ssh-config-key-management, selfhosting index, mastodon-instance-tuning, ansible-check-mode, windows-openssh, windows-sshd, yt-dlp, README, SUMMARY, index Removed: fedora-usrmerge-ebtables-blocker (superseded by prior push)
111 lines
6.6 KiB
Markdown
111 lines
6.6 KiB
Markdown
---
|
|
title: "Fantastical Google Sync Error Flood — Phantom Calendars Fixed via syncselect"
|
|
domain: troubleshooting
|
|
category: productivity
|
|
tags: [fantastical, google-calendar, caldav, sync, macos, syncselect]
|
|
status: published
|
|
created: 2026-04-24
|
|
updated: 2026-04-24
|
|
---
|
|
|
|
# Fantastical Google Sync Error Flood — Phantom Calendars Fixed via syncselect
|
|
|
|
Fantastical floods its macOS unified log with Google Calendar sync errors, the app shows persistent sync failures in the UI, and re-adding the Google account inside Fantastical doesn't fix it. The cause is usually orphan calendar references — calendars that were deleted from Google Calendar but still enabled in Google's per-account CalDAV sync whitelist.
|
|
|
|
## The Short Answer
|
|
|
|
Visit **`https://www.google.com/calendar/syncselect`**, uncheck any calendars that no longer exist or you don't want Fantastical / Apple Calendar to try syncing, click Save. Fantastical's error flood stops within one sync cycle.
|
|
|
|
This is a per-Google-account page — completely independent of Fantastical's settings, and independent of the calendar list inside Google Calendar's main web UI.
|
|
|
|
## Background
|
|
|
|
Google Calendar has **three** separate notions of calendar "visibility" for a given account:
|
|
|
|
| Surface | What it controls |
|
|
|---|---|
|
|
| `calendar.google.com` main UI — calendar list in the left sidebar | What you see in Google's own web interface |
|
|
| `calendar.google.com/calendar/u/0/r/settings/calendar/...` — per-calendar settings | Sharing, notifications, access control |
|
|
| **`google.com/calendar/syncselect`** — sync selection | **What Google exposes to third-party CalDAV/Exchange clients** (Apple Calendar, Fantastical, Outlook, Thunderbird, etc.) |
|
|
|
|
Fantastical talks to Google via CalDAV. It asks Google for the list of calendars enabled for CalDAV sync. If `syncselect` still has a calendar flagged for sync but the calendar has been deleted from Google (or unshared from you), Google returns an inconsistent response — the CalDAV principal lists the calendar ID but any request for its data returns 404. Fantastical dutifully logs an error and retries next sync cycle. Multiply by the number of orphans and you get a flood.
|
|
|
|
Deleting a calendar from Google Calendar's main UI does **not** automatically remove it from `syncselect`. That's the gotcha.
|
|
|
|
## Symptoms
|
|
|
|
- Fantastical UI shows "Sync Error" or a red badge on the account
|
|
- macOS unified log filling with lines like:
|
|
```
|
|
[FBGooglePrincipalSyncSession.m] Unable to find Google Calendar information:
|
|
<calendar-id>@group.calendar.google.com in (<list of real calendars>)
|
|
```
|
|
- `dataaccessd` logs `Error Domain=kEKAccountErrorDomain Code=0` with `lastSyncStartDate = (null)`
|
|
- Fantastical's helper `85C27NK92C.com.flexibits.fantastical2.mac.helper` spams XPC / CoreData token errors every 3 seconds (secondary symptom when the token store gets wedged in the retry loop)
|
|
|
|
## Diagnosis
|
|
|
|
### Step 1 — Spot the phantom calendar IDs in the log
|
|
|
|
```bash
|
|
log show --last 5m --style compact \
|
|
--predicate 'eventMessage CONTAINS "Unable to find Google Calendar"' 2>/dev/null \
|
|
| grep -oE 'information: [a-zA-Z0-9._%@-]+' | sort -u
|
|
```
|
|
|
|
Each line returned is a calendar ID Fantastical is asking Google for that Google can't find.
|
|
|
|
### Step 2 — Get calendar names from Fantastical's local DB
|
|
|
|
The orphan IDs alone look random. To match them to what the calendars were called (so you know what to uncheck in syncselect), query Fantastical's SQLite DB:
|
|
|
|
```bash
|
|
DB="$HOME/Library/Group Containers/85C27NK92C.com.flexibits.fantastical2.mac/Database/Fantastical-8.fcdata"
|
|
|
|
for id in <each-orphan-id-here>; do
|
|
echo "--- $id ---"
|
|
strings "$DB" 2>/dev/null | grep "$id" | head -5
|
|
done
|
|
```
|
|
|
|
Fantastical stores the calendar's display name near each ID in the binary form. You may see names like `Kitchen Lights`, `Major7`, or other labels that remind you what the calendar was used for — often a deleted smart-home automation trigger, an old device's dedicated calendar, a former coworker's shared calendar, a subscribed sports or holiday calendar that moved.
|
|
|
|
### Step 3 — Visit syncselect
|
|
|
|
Open `https://www.google.com/calendar/syncselect` in the same browser you're signed in with. You'll see every calendar Google knows about for this account, with a checkbox per entry:
|
|
|
|
- ✅ Live calendars you want on devices — leave checked
|
|
- ❌ Orphans, former smart-home triggers, deleted shared calendars — **uncheck**
|
|
- Unsure? Cross-reference against the names from Step 2
|
|
|
|
Click **Save**.
|
|
|
|
## Fix
|
|
|
|
1. Uncheck orphans at `https://www.google.com/calendar/syncselect`, click Save.
|
|
2. Let Fantastical complete one more sync cycle (or quit + relaunch for faster turnaround).
|
|
3. Verify the log is clean:
|
|
```bash
|
|
log show --last 2m --style compact \
|
|
--predicate 'eventMessage CONTAINS "Unable to find Google Calendar"' 2>/dev/null \
|
|
| wc -l
|
|
```
|
|
Should return 0.
|
|
|
|
**What you should NOT do as a first attempt:**
|
|
|
|
- Remove and re-add the Google account inside Fantastical. This fixes some orphans but not all — Fantastical's local event cache keeps references to calendars that have associated cached events, so orphans with historical data survive a standard account re-add. Hit `syncselect` first.
|
|
- Delete Fantastical's `.fcdata` SQLite. Nuclear, loses local cache, unnecessary for this specific issue.
|
|
|
|
## Gotchas & Notes
|
|
|
|
- **syncselect is per-Google-account**, so if you have multiple Google accounts in Fantastical, each needs its own visit. The URL will use whichever account you're currently signed in with in the browser.
|
|
- **Calendar deletion from `calendar.google.com` doesn't propagate to syncselect.** This is a Google quirk, not a Fantastical bug.
|
|
- **The same fix applies to Apple Calendar.app** if it's showing the same sync errors — Fantastical and Apple Calendar use identical CalDAV plumbing via macOS's `dataaccessd`.
|
|
- The phantom calendar IDs will remain in Fantastical's `.fcdata` for a while even after the fix — Fantastical doesn't aggressively garbage-collect cached event data. This is cosmetic and doesn't re-trigger sync errors as long as syncselect no longer lists them.
|
|
- The XPC `Unable to create token NSXPCConnection` loop is downstream of the sync error flood — when Fantastical's helper gets wedged on repeated failed syncs, its CoreData-backed OAuth token store can't initialize cleanly. Fixing syncselect + a full Fantastical quit (menubar → Quit Fantastical, not just `Cmd+Q`) + relaunch clears this too.
|
|
|
|
## Related
|
|
|
|
- [[Recap]] skill — uses Google Calendar MCPs that are unaffected by this issue (MCPs go through Google's API directly, not CalDAV)
|
|
- Google's syncselect URL: https://www.google.com/calendar/syncselect
|