Built for WeMakeDevs × Cognee Mergetober.
A meeting report says the launch is on Friday. Someone corrects it to Monday. Your assistant still retrieves Friday.
Nothing crashed. The import worked. The copy is just out of date.
That is the problem behind the Read.ai connector I built for Cognee: importing meeting reports is useful, but those reports do not stop changing once they reach your database.
The demo below uses fictional reports and synthetic model responses with real local Cognee storage. The screenshots are evidence views, not a new chatbot interface or a production deployment.
What it actually does
Choose meeting IDs or a date range, then choose whether to include summaries, transcripts, and metrics. Each available report becomes one document, with the summary first and the transcript last. Participant names, timestamps, and the report link keep the surrounding context attached. Pasted text
The supported workflow runs through sync_read_ai(...), which handles ingestion, recovery, Cognee processing, and cleanup verification. You can then search the selected dataset. Pasted text
For a project assistant, the intended benefit is straightforward: make meeting context searchable and refresh it on subsequent syncs, instead of manually exporting and uploading reports after every correction. The connector supplies the documents; it does not decide which of two conflicting decisions is authoritative.
Authentication uses OAuth 2.1, not the API-key wording in the original issue. The read-ai-connect command handles setup, and token refresh is process-locked so concurrent runs do not refresh the same credential simultaneously. Pasted text
An old meeting can still contain a new edit
The tempting approach is to fetch only meetings newer than the last sync.
But correcting last month’s summary does not change last month’s meeting date. Read.ai’s documented date filters use meeting start time, not report modification time. A date-only cursor would miss that correction.
So the connector uses full upstream reconciliation with incremental downstream processing.
In plain English: recheck the selected reports, render their content consistently, and compare hashes. Under normal operation, send only new or changed content downstream.
This avoids repeated extraction and embedding work for unchanged documents. It does not avoid rereading the selected reports from Read.ai. Pasted text
The successful checkpoint comes last—after ingestion, Cognee’s processing step, and verification. Loading data into staging is not the same as finishing the sync. Pasted text
The implementation flow. Incomplete reconciliation stops before new staging changes; later failures can leave unfinished work without advancing the successful checkpoint.
Two reports, then the changes that matter
The local demonstration starts with two fictional reports: a Friday launch plan and a support handover. Both become searchable documents.
Run the same selection again, and both Data IDs stay the same. The measured synchronization deltas are zero extractions and zero embeddings. Those counters are checked before another search, so query work is not mixed into the sync measurement.
Next, the launch report changes from Friday to Monday. Its meeting ID stays the same. One document changes, the other stays unchanged, and the old document’s references and chunk vectors are removed.
The retrieved chunk contains:
Alphacorp and Sharedcorp moved the launch to Monday after the security review.
That is stored report text, not a generated answer.
Then the launch report is removed from the synthetic provider. Its document and owned chunks disappear during that sync. The handover report and the shared entity it still references survive.
Finally, a simulated 403 permission failure leaves the sync incomplete and preserves the previous corpus and successful checkpoint.
Synthetic reports and model responses, real local storage. The five phases check updates, reuse, removal, and failure handling—not the quality of a real model’s answers.
Missing is not enough evidence to delete
For a date-based selection, a previously imported report must be absent from a complete inventory, return 404 on retrieval, and remain absent from a second complete inventory. All of that happens within the same sync attempt. Explicit-ID selections use two detail requests.
A broken page or permission error is not treated as a deletion instruction.
There is a trade-off: previously imported content can remain locally accessible while permissions are uncertain. This is not complete access-control synchronization. Pasted text
What passed—and what still needs work
The fresh run shown below reports 149 passing tests on Python 3.12.15, with no failures, errors, or skips. Ruff lint, formatting, and the existing offline example also passed. The test run emitted 1,559 warnings.
This run used Cognee 1.6.4, dlt 1.30.0, SQLite, Ladybug, and LanceDB. Only Python 3.12 was exercised in this particular evidence run.
An earlier harness attempt had setup errors. The screenshot records those separately: the external scripts were corrected, the original logs retained, and the connector tests left unchanged.
Fresh local verification for commit 130f52d34ec2. Provider and model responses are synthetic; this is not hosted CI or live-provider acceptance.
There is also a known Cognee 1.6.4 cleanup limitation. A relationship-type vector can remain after its graph node is removed if vector deletion fails. A later retry does not automatically repair it.
The connector detects that leftover vector, raises VerificationError, and refuses to advance the successful checkpoint. Repair still requires a core change or independently verified operator intervention.
A passing test that detects this failure does not mean the failure is fixed. Pasted text
Live Read.ai OAuth, report edits, field availability, and deletion/permission transitions remain unverified. The local results should not be read as proof of a production-ready integration. Pasted text
Top comments (0)