Turning LogRocket Sessions into Searchable Engineering Memory with Cognee

Frontend incidents rarely live in one place. The report starts in support, the browser details live in LogRocket, the release context is in an issue tracker, and the reasoning disappears into a chat thread after the incident is closed.

I wanted to make that operational knowledge searchable. My MergeTober contribution is a LogRocket data-source connector for Cognee, an open-source memory layer. It imports useful session metadata and issue reports through LogRocket's official MCP server, converts them into deterministic documents, and makes those documents available to Cognee search.

The practical goal is simple: an engineer should be able to ask questions such as:

• Which errors are affecting checkout sessions?
• Did the same issue appear across different browsers or releases?
• Which LogRocket sessions provide useful evidence for this incident?
• What issue analyses or reproduction details are already available?

The connector deliberately does not ingest replay payloads, DOM recordings, HAR data, or request bodies.

The issue I chose

Cognee issue #4782 asks for a LogRocket connector with API-key authentication, selectable ingestion of session metadata and issue reports, incremental synchronization, deletion handling, documentation, an example, and tests.

Before coding, I reviewed the existing Notion connector, Cognee's integration guide, and LogRocket's available interfaces. My proposal used the official MCP server and, importantly, committed to verifying pagination, identity, update, and deletion behavior instead of inventing an API contract. The maintainer then assigned the issue to me, and the implementation is now available in cognee-community PR #451.

The real-world workflow

Imagine a support engineer receives several reports that checkout freezes after a new frontend release. Opening individual session links can help, but it does not build reusable knowledge across incidents.

With this connector, a team can run a scheduled import for one LogRocket project:

LogRocket project
    ├── session metadata ─┐
    └── issue reports ────┼─> LogRocket MCP ─> normalized documents
                         └────────────────────> Cognee dataset ─> search

The imported session documents can include the recording/session identity, time range, duration, entry URL, browser/device information, release, and a reference back to LogRocket. Issue documents can include the title, type, occurrence dates, triage information, analyses, reproduction details, messages, and source URL when those fields are returned by MCP.

Cognee can then connect those observations to the rest of an engineering knowledge workflow. Instead of treating a LogRocket session as an isolated artifact, the team can search the accumulated evidence and follow the provenance link when it needs the original source.

Using the connector

The package targets Python 3.11 through 3.13. From the connector directory:

uv sync --locked

Create a local .env file that is not committed:

LOGROCKET_API_KEY=your_project_scoped_key
LOGROCKET_ORGANIZATION=your_organization
LOGROCKET_PROJECT=your_project

The key can also come from DLT's secret providers. The connector resolves credentials from an explicit argument, LOGROCKET_API_KEY, or sources.logrocket.api_key, in that order.

Here is the smallest ingestion-and-search flow:

import cognee

from cognee_community_connector_logrocket import logrocket_source, remember_logrocket


source = logrocket_source(
    organization_id="YOUR_ORG",
    project_id="YOUR_PROJECT",
    resources=("sessions", "issues"),
    session_lookback_days=7,
    issue_lookback_days=30,
    limit=100,
    acknowledge_bounded_results=True,
)

await remember_logrocket(source, dataset_name="logrocket_checkout")

answer = await cognee.search(
    query_text="What errors affect checkout sessions?",
    query_type=cognee.SearchType.GRAPH_COMPLETION,
    datasets=["logrocket_checkout"],
)
print(answer)

The repository also includes a runnable example:

uv run --env-file .env python examples/ingest_logrocket.py

You can select sessions, issues, or both, and use explicit timezone-aware start/end timestamps when a fixed investigation window is more useful than a lookback.

What happens inside the connector

1. It inspects the live MCP contract

The MCP client discovers LogRocket's tool definitions and validates arguments against the schemas returned by the live server. That matters because natural-language search tools can evolve, and assuming a response shape would make the importer fragile.

The package also includes inspection and safe-probe commands for checking tool schemas and response envelopes before a production import.

I first inspected the tools advertised by the live LogRocket MCP endpoint:

uv run --env-file .env cognee-logrocket inspect-capabilities \
  --organization wal246 \
  --project cognee \
  --json

The output verifies that find_sessions and find_issues are present and records the protocol version and advertised schemas. It also reports the missing synchronization guarantees instead of inferring them.

For response validation, the probe reads at most five records and prints only their structure—not the issue text, URLs, users, or other customer content:

uv run --env-file .env cognee-logrocket probe-response \
  --organization wal246 \
  --project cognee \
  --baseline tests/fixtures/live-required-tool-schemas-2026-10-16.json \
  --tool find_issues \
  --arguments-file examples/probe-issue-arguments.json

This run returned two issue structures. The probe confirmed fields such as occurrence timestamps, event count, issue type, triage status, messages, platform type, and URL without printing their values. That live shape became the basis for parsing tests; it was not treated as a permanent undocumented schema.

2. It creates deterministic documents

Sessions use LogRocket's recommended recordingID plus sessionID pair, scoped to the organization and project. Exact duplicate documents collapse to one record. If the same identity appears with conflicting content in a single response, extraction aborts rather than choosing an arbitrary version.

MCP does not currently expose a documented permanent issue identifier, so issue identity uses a project-scoped hash of the validated source URL. That choice is explicitly provisional and documented for replacement when LogRocket exposes a stable issue ID.

Issue messages are canonicalized before rendering, so receiving the same messages in a different order does not create a false edit.

3. It protects dataset ownership

Each dataset is bound to its LogRocket organization, project, and selected resource set. Accidentally reusing the same dataset name for a different project fails before searching. Imports are forced to use merge semantics with id as the primary key.

This prevents two projects—or two incompatible resource selections—from silently contaminating the same memory.

4. It defaults to less sensitive data

User identity and location are excluded by default. User IDs and coarse location require explicit opt-in; names, email fields, and IP fields remain excluded. Free text is checked for common emails, IPv4 addresses, and token-like values. Unsafe source URLs are rejected rather than rewritten because rewriting would break provenance and issue identity.

Credentials are redacted from transport, validation, inspection, retry, and timeout errors. The connector never stores the API key in emitted documents.

5. It fails safely on incomplete or ambiguous results

The connector searches a configured time window and merges returned records. It enforces session timestamps locally using an inclusive start and exclusive end. A response that reaches the configured cap is rejected because it may be truncated; the user can narrow the window or query and retry.

Transient failures use bounded retries, respect valid Retry-After values, and share an overall operation deadline. Authentication and other permanent failures are not retried.

Most importantly, absence is never interpreted as deletion. A partial search response must not erase good memory.

The API contract I could not manufacture

The original issue asks for exhaustive incremental synchronization and deletion propagation. Those behaviors need source guarantees that LogRocket MCP does not currently provide.

I asked LogRocket support directly. They confirmed:

1. MCP has no continuation cursor, and a response below the limit does not prove completeness.
2. There is no updated_since or equivalent change cursor.
3. recordingID plus sessionID is the best available session key.
4. There is no deletion feed or lookup that definitively reports a removed record.

This changes what a correct connector can honestly do. Persisting a high-water mark could skip records that an earlier search silently omitted. Treating missing search results as deletions could erase valid Cognee data. Replacing all records after a non-authoritative search would be even more dangerous.

So the implementation does the safe work available today:

• Re-fetch configurable time windows and merge by deterministic ID.
• Refresh mutable issues whenever they are returned again.
• Preserve records omitted from later searches.
• Reject capped, malformed, out-of-window, or conflicting results.
• Keep deletion inference disabled.
• Document the exact future migration path for a cursor, update feed, stable issue ID, or deletion feed.

This is not a workaround pretending to meet an unsupported contract. It is a usable importer whose failure modes are explicit and non-destructive.

Verification

The test suite covers parsing, structured and text MCP responses, schema changes, retries, timeouts, credential redaction, deterministic IDs, reordered issue messages, privacy controls, result caps, timestamp boundaries, conflicting duplicates, dataset ownership, merge safety, and preservation of omitted records.

The complete offline package suite runs with:

uv run pytest -q

The run completed with 254 passing tests, one optional integration test skipped, and 19 dependency deprecation warnings. I am reporting the warnings rather than cropping them away: the pass result verifies this connector's behavior, not that every dependency is warning-free.

At the time of writing:

Check	Result
Offline tests	254 passed; 1 optional integration test skipped by default
Python versions	3.11, 3.12, and 3.13 configured in CI
Lint and formatting	Passed
Wheel and source distribution	Built successfully
Cognee acceptance path	remember() → search() passed with local Mistral and local embeddings
Live resources	Session metadata and issue reports retrieved through official MCP tools

The local-model acceptance test can be run separately:

LOGROCKET_RUN_COGNEE_E2E=1 \
uv run --env-file examples/ollama.env.example \
  pytest tests/test_cognee_integration.py::test_real_cognee_remember_and_search -q

That test completed in 251.78 seconds using local Mistral and local embeddings. It uses synthetic source records, so it verifies the real Cognee ingestion, processing, persistence, and search path without publishing private LogRocket data. The normal offline suite does not require a LogRocket key.

What I learned

The most important connector code is often the code that refuses to guess.

A natural-language search tool can be very useful for discovery and focused imports without being an authoritative database listing. A merge can be safe without being a complete incremental sync. A stable-looking URL can be useful as provisional identity without being presented as a permanent source ID. And an empty response can mean many things other than deletion.

This project reinforced four engineering rules for data connectors:

1. Inspect the live capability contract before designing state.
2. Separate useful ingestion from completeness guarantees.
3. Make privacy and provenance defaults part of the data model.
4. Prefer preserving known-good data over destructive guesses.

If LogRocket later adds exhaustive pagination, a reliable update cursor, stable issue IDs, and machine-readable deletion records, the connector already has documented extension points for adopting those capabilities without changing its public purpose.