One calendar, two names: fixing duplicate memories in Cognee's Google Calendar connector

A developer contributed a fix to Cognee's open-source Google Calendar connector, which had been storing every event twice when a user configured both the "primary" alias and the calendar's real email-address ID. The patch reuses the connector's existing calendar listing to treat both spellings as one key, keeps the first configured spelling so default setups see no change, and lets the existing forget path clean up duplicates from earlier syncs. Three new tests cover the behavior, run against an in-memory fake of the Calendar API.

AI agents are only as good as what they remember. Cognee https://github.com/topoteretes/cognee is an open-source memory layer for agents: you hand it documents, chats or data, and it builds a knowledge graph the agent can query later. For Mergetober WeMakeDevs × Cognee I spent my contribution on the Google Calendar connector, which turns your calendar into agent memory, so you can ask things like "what did I agree to in last week's design review?" or "when is my next 1:1 with Priya?". The connector is a dlt source. You hand it to Cognee in one call: python import cognee from cognee community connector google calendar import google calendar source await cognee.remember google calendar source calendar ids= "primary" , dataset name="calendar", primary key="id", write disposition="merge", answer = await cognee.recall "When is my next design review?" Each event becomes a short text document "Calendar event: Design review / When: ... / Attendees: ..." , which Cognee chunks and turns into entities and relations. Later syncs use Google's sync tokens, so only changed events are re-read, and deleted events are forgotten. In Google Calendar your main calendar has two names: the alias "primary" , and its real id, which is your email address. The connector's helper script examples/login.py lists your calendars by their real ids, so a natural setup looks like this: GOOGLE CALENDAR IDS=primary,me@gmail.com The connector treated those as two different calendars. It kept separate sync state for each and built row ids from the configured string gcal:primary:<event and gcal:me@gmail.com:<event , so every event was stored twice . That means double the LLM calls during cognify and duplicate facts in the graph. It's the kind of quiet bug that never crashes anything; your agent just gets noisier and more expensive. The sync already lists your calendars to get their display names, and that listing marks which one is primary. So the fix reuses it: "primary" and that id as the same key, and keep only the first spelling you configured. Keeping the first spelling matters: someone with the default "primary" setup sees no change at all same row ids, same sync state, nothing re-ingested . And if an earlier sync already stored both copies, the second spelling now counts as a calendar removed from the config, so the connector's existing forget path cleans the duplicates up on the next run. The connector's tests run against an in-memory fake of the Calendar API, so no Google account is needed. I added three tests: both spellings sync as one calendar, the first spelling is kept, and a leftover duplicate from an older sync gets forgotten. Then I ran the whole suite plus ruff on Python 3.11 and 3.13 with GitHub Actions on my fork. Links: