DEV Community: Vinayak Sonthalia

Building a Postman Connector for Cognee: What I Learned About Safer Syncs

Vinayak Sonthalia — Sat, 31 Oct 2026 18:35:58 +0000

A Postman sync that knows when to stop

What repeated review taught me about snapshots, deletion safety, privacy, and proving a Cognee connector works end to end.

A Postman request changed from “Aster lives in Oslo” to “Aster lives in Lima.” After syncing the edit into a local Cognee setup, a search found Lima; checks of the stored content found no remaining Oslo text. When I deleted the synthetic request, the corresponding Data, graph, and vector records were empty too.

That small lifecycle captures the difficult part of building a connector: getting fresh content in is easy to demonstrate. Getting changes and removals right, without deleting unrelated data or leaking secrets, takes more work.

The sync is a snapshot, not an append

A connector that only adds documents can leave old facts behind. The Postman source therefore emits a complete snapshot for its own stable resource identity. Unchanged documents are retained from cache, while changed and removed documents flow through Cognee’s replacement path.

flowchart TD
    A[Validate account and workspace] --> B[Read collection inventory]
    B --> C{Inventory complete and stable?}
    C -- No --> X[Stop; keep prior snapshot]
    C -- Yes --> D[Fetch changed trees; reuse unchanged cached rows]
    D --> E[Build complete retained snapshot]
    E --> F{Removal is ambiguous or exceeds guard?}
    F -- Yes --> Y[Stop and report UIDs for explicit confirmation]
    F -- No --> G[Publish scoped replacement to Cognee]
    G --> H[Verify Data, graph, vectors, and search]

This design keeps unchanged content in the snapshot instead of confusing “not fetched this time” with “deleted.” Resource names provide isolation between sibling sources. A deliberate selection change can retire content from one resource without wiping another.

Deletion is where an ordinary inventory comparison becomes dangerous. A partial listing caused by access changes can resemble mass deletion. The connector waits for matching inventory passes before trusting changed listings, refuses to clear a populated cache from an empty inventory without confirmation, and keeps pending removals across runs. Pending entries do not vanish just because a scheduled sync was delayed.

These checks reduce accidental loss; they do not reveal why Postman stopped showing a collection. It may have been deleted, moved, unshared, or hidden by permissions. The documented removal policy makes that tradeoff explicit and allows callers to require confirmation.

Privacy is a boundary, not a regex promise

A collection can place credentials in auth settings, variables, query parameters, custom headers, URL paths, or request bodies. Early review rounds exposed both sides of the problem: redaction that ate ordinary words, and secrets that still appeared in generated prose.

Each reported example became a regression case. The current filtering covers known sensitive fields and credential patterns, including secret variables, sensitive body fields, custom auth headers, query values, long token-like strings, hex tokens, JWT shapes, and known path patterns. Raw request trees are not persisted, and auth, scripts, examples, and raw values are omitted from rendered documents.

That is best-effort filtering, not universal secret detection. A short value can be indistinguishable from a normal word; an unusual credential can evade known patterns. The documentation says so. Users should review source collections and provide explicit values to redact where needed.

Review comments became executable cases

The PR went through several rounds of detailed review. Feedback covered false deletion, inventory gaps, documentation-only collections, redaction, request URLs, retry limits, unnecessary API calls, and error reporting. The useful shift was to stop treating each comment as a local patch and instead ask: what small test would fail if this happens again?

The latest recorded offline suite reports 185 passed and 1 skipped. The skipped test is an optional model integration test, so it is not counted as a pass in that run. The validation record also includes several installed-wheel Python/Cognee/dlt combinations, a locked development environment, and lint, format, lock, and wheel checks. Those are recorded results for the listed environments, not proof of every allowed version or backend.

Testing with local Cognee stores

Mocked Postman responses are useful for repeatable edge cases, but they cannot show that Cognee’s stores update as expected. A separate local run used a synthetic Postman collection and actual Cognee Data, graph, and vector stores. It covered an initial ingest, unchanged sync, edit, and deletion, with store inspection as well as search.

The local model-backed setup used cached models; it did not use Cognee Cloud credits or paid model calls. Provider writes were limited to synthetic test collections, and a postflight check confirmed that the original collection remained and the synthetic fixtures were removed.

The evidence has boundaries: the provider and Cognee runs use a small synthetic workspace and the recorded versions. They do not prove behavior on every backend, every provider permission setup, or every possible partial failure. The package’s README.md has the quickstart; VALIDATION.md and VALIDATION_RESULTS.json describe reproducible commands, environments, and limitations. The authenticated lifecycle requires a Postman API key and a dedicated test workspace.

What changed in how I build connectors

This started as an API client and document mapper. It became a synchronization system with state, identity, deletion policy, privacy boundaries, and recovery behavior. Those are part of the product contract, so they need tests and documentation of their own.

I also learned that review is most useful when it produces a sharper test. A comment about a disappearing collection can become a multi-run regression. A redaction example can become a fixture that checks both what must disappear and what ordinary prose must preserve. That turns review from a list of opinions into a growing set of concrete behaviors.

The work is proposed in Cognee Community PR #366.

When a Jira Issue Disappears: Lessons from Building a Cognee Connector

Vinayak Sonthalia — Sat, 31 Oct 2026 18:33:33 +0000

When a Jira issue disappears, should its memory disappear too?

What we learned building a Jira connector for Cognee: synthetic test data, careful deletion semantics, and the bugs that appeared only after we kept reviewing.

A Jira connector sounds like a data plumbing task: read issues, comments, and attachments, turn them into documents, and make them searchable. The harder question came later: when Jira stops returning something, should Cognee forget it?

That question turned a small connector project into a lesson in uncertainty, test design, and why “all tests pass” is a milestone—not a guarantee.

Start with data we could safely break

I created a free Jira Cloud test site and a tiny synthetic project: two issues about Orion retry limits and Vega queue limits, with comments and a text attachment. The content was invented so we could know exactly what the connector should find, edit, and remove without bringing real work data into an early test.

The first sync produced five documents: two issues, two comments, and one attachment. On an unchanged sync, the documents remained while the connector reused the issue descriptions. Comments and attachment inventories were refreshed independently. A comment can change without a useful parent-issue timestamp change, so relying on the parent cursor alone could leave old words behind.

We checked the resulting memory in Cognee’s Data records, graph, and six vector collections. Search results alone are not enough evidence that removed content has actually been cleaned up.

Here is the basic path we wanted to verify:

Jira issues ─┬─> issue documents ─┐
             ├─> comment documents ├─> complete replacement snapshot ─> Cognee
             └─> attachment text ──┘
                                      │
                                      └─ empty snapshot ─> remove old corpus

“Missing” is not the same as “deleted”

An issue can disappear from a query because it was deleted. It can also move, stop matching a JQL filter, or become hidden after an access change. Jira search is eventually consistent, too. From a missing result alone, the connector cannot know which explanation is right.

We made that tradeoff explicit in the API. Callers must choose a policy:

mirror_visibility replaces the corpus with what the account can currently see. It supports next-sync forgetting when access stays complete and stable.
require_confirmation pauses when known documents disappear, so the caller can check the situation and acknowledge specific removals.

Neither policy turns absence into proof of deletion. Visibility mirroring can remove content after access changes; confirmation can delay a real deletion. The choice belongs in configuration and documentation, not hidden behind a default.

Reviews changed our understanding

The first strict review rounds found problems that happy-path tests had missed. Our main example selected the guarded policy, so it did not demonstrate automatic next-sync removal. An empty snapshot also needed to create a physical staging table; otherwise, after dlt staging state was lost, Cognee could retain old Data records. And our renderer flattened superscript and subscript, changing the meaning of expressions such as 10⁻³.

Fixing those issues was not the end. A later review modeled Jira’s general search returning stale membership while reconciliation returned the current result for specific issue IDs. We were adding reconciled results to the general list but ignoring IDs excluded by reconciliation. That kept an issue’s documents even after it stopped matching the selected JQL filter.

Our first correction removed the issue from the current list. A repeat run exposed a second bug: stale general search could reintroduce it. The final logic reconciles both retained and newly discovered IDs in batches, then lets each complete reconciliation batch replace general search membership for those IDs. This prevents a known filter exit from being resurrected while leaving unknown discovery subject to eventual consistency.

Another review caught a usability bug: a raw ORDER BY regular expression rejected a valid filter such as summary ~ "order by". We changed the check to distinguish quoted JQL values from a real ordering clause.

The review-and-fix loop looked like this:

Review finding
     ↓
Small reproduction
     ↓
Fix and add regression test
     ↓
Strict review again
     ↓
New edge case? ── yes ──> repeat
     │
     no
     ↓
Rebuild and verify the exact package

We also found two test-harness failures along the way. One subprocess imported an older installed package instead of the source under test. A global HTTP mock counted unrelated telemetry requests as Jira retries. Both taught us to verify what a test actually loaded and intercepted, rather than trust the test’s name or shell exit code.

What failed	What we changed	The lesson
Default workflow did not forget automatically	Require an explicit removal policy; make the main example choose visibility mirroring	Make important behavior visible in the API
Empty rebuilt staging left old Cognee records	Materialize the empty resource table	Test empty results and recovery, not only populated syncs
Superscript/subscript lost meaning	Preserve the notation and invalidate old cached rendering	Text conversion can change meaning, not just formatting
Stale general search retained and later resurrected filtered issues	Reconcile retained and discovered IDs; replace membership per completed batch	Test repeated runs after the first fix
Quoted “order by” text was rejected	Detect ordering clauses outside quoted strings	Validate query structure, not keyword appearances
Subprocess tested an old install; HTTP mock counted telemetry	Bind subprocesses to the imported package and scope the mock to the Jira client	Check the test harness itself

What we verified—and what remains unknown

The final local run passed 69 tests on each of Python 3.11, 3.12, and 3.13. We also tested an authenticated synthetic Jira lifecycle, recovery after downstream ingestion failure, and cleanup after staging was rebuilt. With two overlapping corpora, we removed one corpus’s facts while preserving the other’s, then removed the remaining facts when its owner retired them. We inspected Data, graph, and vector stores through the cleanup steps.

An independent GPT-6.1 Sol High review found further defects in two later rounds. After the fixes, it reran the source and installed suites and ten additional adversarial probes. The final report found no further actionable issues within its review scope. These are local results—not GitHub CI, a guarantee of correctness, or production experience.

The connector does not make Jira snapshots atomic. Unknown issues can appear late; access changes can look like deletions; and the first version supports a limited set of attachment formats and unscoped API tokens. The README describes the size, timeout, concurrency, and compatibility limits as well.

Where the work stands

The connector is proposed in PR #462. As of October 31, 2026, it is open, with no review comments or GitHub checks listed. It has been tested locally against synthetic Jira data and has not been deployed to production.

The most useful lesson was to test the uncomfortable transitions: a comment changes quietly, an issue leaves a filter, staging disappears, or the snapshot becomes empty. Those are the moments when stale knowledge can survive. Reviewing those cases repeatedly made the connector—and our evidence for it—more trustworthy.

Building a Grafana Connector for Cognee: What I Learned About Syncing Safely

Vinayak Sonthalia — Sat, 31 Oct 2026 18:31:52 +0000

Building a Grafana Connector for Cognee: What I Learned About Syncing Safely

I’ve been building a Grafana connector for Cognee as part of Issue #4779. The implementation is in PR #458, which is open for maintainer review. This post describes the implementation and lessons so far; it is not a claim that the PR is merged or that every Grafana setup is supported.

The idea is simple: make selected dashboard context and human annotations searchable alongside other knowledge in Cognee. The engineering turned out to be less about making HTTP requests and more about deciding what the connector can safely conclude from them.

What the connector reads

The initial connector renders selected dashboards, panel titles and descriptions, and human annotations into documents for Cognee. It does not run dashboard queries or ingest metric values. Identity and selection matter: a dashboard UID is used as the dashboard identity, annotations use their IDs, and each connector resource maps to one separately managed corpus.

Before implementing it, I studied existing Cognee connector patterns and the Postman connector PR #366. That review helped me think about the full lifecycle: extraction, staging, retries, replacement, and cleanup—not only the API call itself.

The central challenge: when is a snapshot complete?

Consider a sync that sees fewer dashboards than last time. A dashboard might really have been deleted. But access could also have changed, pagination could be incomplete, or a request could have failed. If the connector treats every missing item as deleted, a temporary visibility problem can erase good data.

The connector therefore validates the read and its authority before allowing a new snapshot to replace the prior staged view. If it cannot establish a usable snapshot, it fails the extraction so that uncertainty does not become deletion.

flowchart TD
    A[Start sync] --> B[Check account, role, and required permissions]
    B --> C[Read selected dashboard inventory]
    C --> D[Read annotation history]
    D --> E[Recheck authority and dashboard inventory]
    E --> F{All reads and checks complete?}
    F -- No --> G[Fail extraction; do not publish replacement snapshot]
    F -- Yes --> H[Render selected content and stage snapshot]
    H --> I[Cognee processes documents and cleanup]

That leads to the principle I’ll carry into future sync work: absence is meaningful only when the read was complete enough to trust.

Permissions are part of the design

On the tested Grafana release, the organization-wide reads needed for this reconciliation were verified using an organization Admin service account. The connector sends GET requests, but the account role also permits writes. Those are separate facts: read-only request behavior does not mean the credential itself is read-only.

The PR documents this as a limitation and asks maintainers to decide whether to accept the initial requirement or pursue a narrower authority strategy. The connector refuses a Viewer account because a filtered view could be mistaken for a complete inventory and cause false deletion.

This was a useful security lesson: explain both the operations your code performs and the privileges held by the credential that performs them.

Deliberately narrow support

The implementation targets Grafana OSS 12.3.1, organization 1, the default namespace, the v1beta1 dashboard API with classic schema 42, and SQL-backed annotations. Library panels are refused instead of silently omitted. Other Grafana versions, Cloud, organizations, schemas, and annotation stores need separate validation.

The narrow contract makes the current behavior easier to reason about, but it is not a substitute for broader compatibility work. The PR asks for maintainer input on the initial boundary and calls out validation still needed.

Incremental work is not an incremental feed

An unchanged dashboard can reuse cached rendered content, reducing repeated rendering and downstream work. However, this connector still reads complete dashboard inventories and scans the configured annotation history. “Incremental” here describes reuse and processing, not a guarantee that Grafana sends only changed records.

flowchart LR
    A[Full provider inventory] --> B{Previously seen revision?}
    B -- Same --> C[Reuse cached rendered row]
    B -- New or changed --> D[Render selected fields]
    C --> E[Build verified replacement snapshot]
    D --> E
    E --> F[Cognee ingestion and reconciliation]

Making this distinction explicit matters for both performance expectations and correctness: the connector must still verify enough of the source to reconcile removals safely.

Redaction and selected context

Dashboards can contain more than useful prose. The connector uses an allowlist of selected fields and avoids ingesting query targets, datasource settings, variable values, raw options, and secure configuration. It also applies best-effort filtering for credentials and accepts explicit redaction values for known secrets.

Redaction is not a guarantee that every secret in arbitrary prose will be detected. That limitation is documented, and users should review selected content and supply known secret strings explicitly. This reinforced another lesson for me: data minimization is stronger than relying on filters after collecting everything.

How I tested it—and what that does not prove

The work includes tests for identity, annotations, permission changes, incomplete reads, selection changes, redaction, retries, and deletion behavior. I also ran installed-wheel tests with Python 3.11, 3.12, and 3.13, plus lifecycle checks against a disposable Grafana instance and local Cognee stores.

Those results provide evidence for the exercised paths; they do not prove universal correctness. Broader Grafana versions, other storage backends, arbitrary cross-store failure recovery, and every permission or concurrency interleaving remain outside what these checks establish. The PR is still open for review, and maintainer feedback may change the design or scope.

What I’m taking forward

This project changed how I think about connectors. A connector is not just an API wrapper. It is a trust boundary and a data lifecycle: it decides what to collect, how to identify it, when a snapshot is complete, how to handle uncertainty, and when removal is safe.

The hardest part was not fetching dashboards. It was making sure the system does not confuse “I can’t see it right now” with “it no longer exists.” That distinction—and the need to document limits honestly—is the learning I’ll take into the next integration.

The next step is maintainer review of the permission model, support boundary, and remaining validation work in PR #458.

I Built an AI That Forgets on Purpose — and It Made It Smarter

Vinayak Sonthalia — Sun, 05 Jul 2026 16:02:52 +0000

It's 3am, your site is down, and your AI confidently tells you to fix a server that was deleted a month ago. Here's why I spent a week building the delete key.

The night my own assistant lied to me

I was building an incident-triage assistant — the kind of thing an on-call engineer asks for help at 3am when the site is down. Feed it your team's runbooks, ask it what to check, get a calm answer back. It worked. I was pretty happy with it.

Then one evening, while testing, it told me to go fix a server we'd switched off a month earlier.

Me: auth-service is slow, what do I check?
Assistant: Check the legacy-cache — flush and resize the cluster!

Confident. Detailed. Completely wrong. The legacy-cache didn't exist anymore. And here's the thing that stuck with me: the assistant hadn't malfunctioned. It did exactly what I built it to do — remember. It just remembered something it should have forgotten.

The bug wasn't a bug. It was the whole design.

Look at how everyone builds "AI memory" right now — they're all racing in one direction: remember more. More documents, longer history, bigger context.

It's genuinely useful — until you notice the quiet assumption holding it all together: every fact we remember stays true forever.

Facts do not do that.

Servers get retired. People change teams. Last year's clever fix becomes this year's outage. A bigger memory just hands you more stale facts, with no way to tell "still true" from "used to be true."

Think of your phone's contacts: if you only ever add numbers, eventually you call an old friend and a stranger picks up. The bug was never a number you forgot — it was a number you kept when you shouldn't have.

So I stopped asking "how much can it remember?" and started asking:

Can it stop remembering the things that have stopped being true?

I named the project Lethe, after the river of forgetting. (I'm not subtle.)

Watch it forget, live

I retire the legacy-cache — decommission it, gone — and ask the exact same question as before, word for word:

Before: "Check the legacy-cache, flush and resize the cluster." (go fight the ghost)

After the delete, same question: "Check the session-store connection pool and its hit rate…"

The answer flips. And when I pushed it — "okay, then what IS the legacy-cache?" — it said:

"The legacy-cache is not documented in the runbooks."

Not "I remember more." Instead: "I stopped remembering the wrong thing" — and it admits it doesn't know rather than confidently inventing something. Which, for an AI, is basically emotional maturity.

How it works (the two-minute version)

Lethe is built on Cognee, an open-source memory engine. You feed it runbooks as plain English — no tags, no schema — and one cognify() call builds two stores at once: a knowledge graph (Kùzu) and a vector index (LanceDB).

Ask a question → vector search finds what's relevant, the graph adds what's connected, and the model writes one runbook-style answer — every claim cited to its source.

And when a system dies? forget() — a real hard delete: raw files, graph nodes, edges, embeddings. Gone. With a printed receipt and a live re-query proving it.

There's a gentler layer too: a curation loop that scores memory health, reversibly down-weights aging runbooks, and queues true deletions for a human to approve. Nothing gets hard-deleted without a person saying yes.

Then I tried, on purpose, to prove myself wrong

Cognee advertises several superpowers beyond forgetting. Instead of listing them all as my features, I raced them against plain, boring RAG — same docs, same model, temperature zero:

Multi-hop? Tied at this scale. Learning from feedback? No clean win. Blast-radius? Tied. Only forget produced something RAG-with-the-same-stack fundamentally cannot do. So I cut the three ties as headline claims and built the whole product around the one provable win.

Then I measured forgetting itself — twice, with a blind judge from a different model family scoring every answer:

(Fun confession: my first benchmark got thrown out — it graded whether the forgotten word was absent, which is circular. The blind-judge version grades correctness.)

The bug that almost killed the demo

For a while, the demo was haunted: the same question usually returned a full sentence — but sometimes it fired back a single word: "legacy-cache." Just the word.

I cleared the suspects one by one — the build (glitch happened on the same saved graph), my phrasing, retrieval (the assembled context was rich and correct every time). The culprit? A line buried in the tool's default prompt: "answer as briefly as possible." On a vague question, that collapses to the single most relevant word. The model wasn't broken — it was obeying its instructions a little too well.

One custom prompt later, three separate bugs disappeared at once. When an LLM writes your final answer, the instruction you hand it is the most powerful lever you have.

Go poke it yourself

🌊 Try it live (no signup): vinayaksonthalia-lethe.hf.space — ask, decommission, re-ask, watch it flip
🎬 2-minute demo: youtu.be/3840gxTZWxY
📚 Every design decision, documented: 30 chapters at /learn
💻 Code: github.com/vinayaksonthalia/lethe

Everyone's building memory that only grows. Lethe is the other half — memory that knows when to let go.

Thanks for reading. Now go delete something. 🌊

Built solo in one week by Vinayak Sonthalia (final-year B.Tech) for the WeMakeDevs × Cognee hackathon.