Skip to content

fix(server): use dedicated client for /messages background ingest#1622

Open
Algorhythmicss wants to merge 1 commit into
getzep:mainfrom
Algorhythmicss:fix/messages-endpoint-closed-driver
Open

fix(server): use dedicated client for /messages background ingest#1622
Algorhythmicss wants to merge 1 commit into
getzep:mainfrom
Algorhythmicss:fix/messages-endpoint-closed-driver

Conversation

@Algorhythmicss

Copy link
Copy Markdown

Problem

POST /messages returns 202 but never persists anything — MATCH (n) RETURN count(n) stays 0 and /search always returns {"facts": []}.

The endpoint queues add_messages_task onto the module-level AsyncWorker, but the task closes over the request-scoped graphiti client from the get_graphiti FastAPI dependency. That dependency's finally: await client.close() runs as soon as the HTTP request returns (202) — before the queued job executes. When the worker later runs the job, the Neo4j driver is already closed → DriverError('Driver closed').

Because the worker loop only catches asyncio.CancelledError, that exception propagates out of while True and silently kills the worker, so all subsequent ingests are dropped too with no log output.

Fix

  • Extract client construction into build_graphiti(settings) in zep_graphiti.py.
  • add_messages_task now builds and closes its own client (independent of request scope).
  • The worker loop catches and logs generic exceptions so one failing job no longer kills ingestion.

Testing

Verified on the Neo4j 5.26.2 backend (docker compose up): after the fix, ingesting messages creates Entity nodes and bi-temporal RELATES_TO edges, and POST /search returns the extracted facts with valid_at / invalid_at metadata.

Note: verified against the Neo4j path only; I did not exercise the FalkorDB profile or run the full server test suite.

🤖 Generated with Claude Code

The /messages endpoint queues ingestion onto a background AsyncWorker but the
queued task closed over the request-scoped `graphiti` client from the
`get_graphiti` FastAPI dependency. That dependency's `finally: await
client.close()` runs when the HTTP request returns (202), closing the Neo4j
driver before the queued job executes. The job then raised
`DriverError('Driver closed')`, and because the worker loop only caught
`CancelledError`, the exception silently killed the worker and every ingest
became a no-op (0 nodes persisted, /search always empty).

- Extract client construction into `build_graphiti(settings)`.
- `add_messages_task` now builds and closes its own client.
- Worker loop catches and logs generic exceptions so one bad job no longer
  kills ingestion.

Verified on the Neo4j backend: entities and bi-temporal RELATES_TO edges are
created and /search returns facts.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@zep-cla-assistant

Copy link
Copy Markdown
Contributor


Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. For privacy information, see our Privacy Notice. You can sign the CLA by just posting a Pull Request Comment same as the below format.


I have read the CLA Document and I hereby sign the CLA behalf on myself, e-mail: example@example.com

or

I have read the CLA Document and I hereby sign the CLA behalf of my company, e-mail: example@example.com

Signature is valid for 6 months.


This bot will be retriggered when the Contributor License Agreement comment has been provided. Posted by the CLA Assistant Lite bot.

@Naseem77

Copy link
Copy Markdown
Contributor

@Algorhythmicss Reproduced both issues: queued /messages jobs ran on a client FastAPI had already closed ('Driver closed'), and one failing job killed the worker loop permanently. With your change ingestion gets its own client and the worker survives failing jobs. Verified with live requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants