A project record gets deleted. Its old context should leave Cognee on the next successful sync.
An Airtable request fails. The last successfully imported data should stay.
Those are opposite outcomes. A connector that reduces both to “nothing came back” can either keep obsolete information or erase information it was never told to delete.
That distinction shaped my contribution to Cognee issue #4766 for WeMakeDevs × Cognee Mergetober. After assignment, I added the Airtable connector in cognee-community, without changing Cognee core. There is also an earlier Airtable proposal, PR #198, which deserves acknowledgment. Pasted text
A handover question, not another export
Consider a team keeping project owners, blockers, and decisions in Airtable. During a handover, someone asks:
What is blocking the project handover?
An export can answer that question once. A useful integration needs to keep the answer’s supporting information current as fields and comments change.
The connector turns selected records into documents, including comments when enabled. Table schemas—the descriptions of the fields—become separate documents. Pasted text
The demonstration here uses synthetic project facts, mocked Airtable responses, and deterministic model outputs, with real SQLite, Ladybug, and LanceDB storage. These are local verification reports, not a live Airtable deployment. image(20261009-051147)
Change the comment. Leave the timestamp alone.
The first capture retrieves this passage:
The blocker is AmberPermit approval.
After a comment-only edit, the retrieved passage becomes:
The blocker is TealCertificate approval.
The record timestamp stays at 2026-01-01T00:00:00Z. Neither distinctive fact appears in the question.
Finding the replacement is only half the check. The report also checks that AmberPermit is absent from the graph and vector storage, while TealCertificate appears in retrieved passages. All nine assertions in this scenario passed.
Comment-only update with an unchanged timestamp. These are selected CHUNKS retrieval excerpts, not generated answers. Airtable and model responses are controlled substitutes; storage is real.
Why the connector reads more than it writes
The implementation keeps per-table modified-time watermarks, but timestamps do not decide everything. Comments and schema need independent checks; computed values, blank timestamps, and restored records complicate timestamp-only filtering.
The design is full source reconciliation with incremental document emission: read the complete selected source, compare it with persisted document fingerprints, then emit changed documents and confirmed deletion markers.
That means incremental writes, not an API request that fetches only changed records. Pasted text
The documents themselves are normalized consistently. Field and comment ordering is deterministic. Cursor values and temporary attachment URLs are excluded, so those transport details do not become artificial content changes. Pasted text
The example passes this configuration to remember():
dlt_config={
"primary_key": "id",
"write_disposition": "merge",
"max_rows_per_table": 0,
}
Explicit merge keeps unchanged documents in staging—the intermediate storage before Cognee processes them. Cognee’s default replace would discard those unchanged staged documents. The unlimited read keeps the retained document set available for reconciliation. Pasted text
Two empty-looking outcomes that must disagree
In one fixture, a selected table is emptied successfully. Its known record rows are removed, but three Cognee documents remain: that table’s enabled schema, an independent control record, and the control table’s schema.
Zero records in one table does not mean zero documents everywhere.
In the contrasting fixture, an earlier table read succeeds, but a later required comments request returns HTTP 403. The connector aborts before publishing the partial result. Existing staging, connector state, and documents remain unchanged.
Two separate local scenarios: a confirmed empty table removes records; a failed required read preserves the prior state. The report records 23/23 and 14/14 passing assertions respectively.
Required reads finish before any changes are emitted. Only a complete inventory is used to identify missing records. A confirmed disappearance of a previously synchronized, still-selected table removes its records and schema. Deselecting a table, however, preserves its earlier imports. Pasted text
Completing pagination is still not the same as obtaining a transactionally consistent upstream snapshot.
Recovery worked in specific tests. One result remains unexplained.
Staging can succeed before Cognee stores or processes the documents. In the captured storage-failure scenario, an unchanged retry brings the staged SilverRunbook fact into document storage without another upstream edit.
Cleanup has a more important caveat. With an injected deletion failure, remember() reports completed while stale graph content remains. The isolated cleanup retry and final chained capture passed.
An earlier chained attempt did not. Document/vector content remained, and the second process exited with -11. The report explicitly preserves that inconsistency. A later passing run does not establish its cause or demonstrate that it has been fixed. image(20261009-051204)
The supported claim is recovery in the recorded successful scenarios—not that cleanup recovery is consistently reliable. The unexplained failure still needs investigation.
What the local checks actually say
The October 9 report for revision 862c98b09bbb records 107 passing tests on Python 3.12, with no failures, errors, or skips. Python 3.11 compatibility records 97 passes, and targeted core checks record 33.
Another available regression group records 25 passes and one skip; the broader connector-regression check is marked blocked. Lint, formatting, package build, and installed-wheel smoke checks passed. Compatibility reruns are not additional unique tests.
These results concern the local fixture setup. Live Airtable behavior, real-model answer quality, and hosted CI remain unverified in this report. image(20261009-051205)
Try the handover workflow
Use a disposable base. Give its Personal Access Token data.records:read and schema.bases:read, plus data.recordComments:read when comments are enabled. Pasted text
Add a Last modified time field to each selected table, tracking All editable fields with time included. Check that setting in Airtable’s interface; the connector cannot conclusively establish it from metadata. Pasted text
From packages/connector/airtable/ on the implementation branch, configure Cognee’s model providers as described in the README, then run:
uv sync --frozen --all-extras --python 3.12
export AIRTABLE_ACCESS_TOKEN="your-personal-access-token"
export AIRTABLE_BASE_ID="appYourBaseId"
export AIRTABLE_TABLE_IDS="tblYourTableId"
export AIRTABLE_QUESTION="What is blocking the project handover?"
uv run --frozen python examples/example.py
Add a distinctive blocker, retrieve it, edit only its comment, and run the example again. Then delete a record and check what remains. The example retrieves dataset-scoped passages; it does not generate an answer or run continuously.
Full reconciliation reads unchanged records and enabled comments, so polling large tables has a cost. Select only needed tables and disable unnecessary comments. Attachments contribute stable metadata, not downloaded file contents. Pasted text Pasted text
Importing the new fact is the visible part. Removing the old one—and knowing when not to—is the harder requirement.
Top comments (1)
The distinction between complete pagination and a consistent snapshot deserves its own negative fixture: move a known record across the pagination boundary while the inventory is being read, so every request succeeds but that record is absent from the assembled inventory.
Would that absence become a deletion marker immediately, or is there a confirmation step before deleting previously imported context? Rechecking missing IDs, or marking them pending deletion until a later complete inventory, would give that uncertainty somewhere to live. This is separate from the 403 preservation case and the downstream cleanup retry. I haven't run the connector; it's a suggested upstream-consistency fixture based on the reconciliation caveat you explicitly kept in the post.