[ferhimedamine]

Closes #3516
Supersedes #3519 (the document-store integration is now included here; #3519 is closed as redundant)

Summary

Adds integrations/dakera/ — a single dakera-haystack package for Dakera, a self-hosted memory server. It exposes two complementary integrations that share one Dakera server:

• Memory — DakeraMemoryStore, DakeraMemoryRetriever, DakeraMemoryWriter: conversational, decay-weighted memory over Dakera's memory API (POST /v1/memory/store, POST /v1/memory/recall). ChatMessage-based; the server handles embedding and importance scoring.
• Document store — DakeraDocumentStore, DakeraEmbeddingRetriever: a standard Haystack DocumentStore over Dakera's vector-namespace API (via the official dakera Python SDK), for embedding-based document retrieval (RAG) with metadata filtering.

This follows the structure of integrations/mem0/ and (for the document store) the integrations/pinecone/ conventions.

Components

Class	Kind	Description
DakeraMemoryStore	Client	Memory API client; X-API-Key auth
DakeraMemoryWriter	@component	Persists ChatMessage text as memories → memories_written: int
DakeraMemoryRetriever	@component	Decay-weighted recall → memories: list[ChatMessage]
DakeraDocumentStore	DocumentStore	Vector-namespace document store (sync + async) backed by the dakera SDK
DakeraEmbeddingRetriever	@component	Dense document retrieval with metadata filtering

Tests

• Unit tests use respx (memory) and AsyncMock/mocked SDK (document store) — no live server needed in CI.
• Integration tests (test_memory_integration.py, test_document_integration.py) run against a live Dakera server and are skipped unless DAKERA_API_URL / DAKERA_URL is set. The document-store suite reuses Haystack's CountDocumentsTest / DeleteDocumentsTest / WriteDocumentsTest mixins.

cd integrations/dakera
hatch run test:unit          # mocked, runs in CI
hatch run test:integration   # requires a live Dakera server

Notes

• dependencies = haystack-ai>=2.28.0, httpx>=0.27.0, dakera>=0.12.8.
• Self-host via dakera-deploy; the REST API listens on port 3000 by default.

[ferhimedamine]

Fixing the test-api-reference-build CI failure — the pyproject.toml referenced readme = "README.md" but the file was missing from the integration directory. Added integrations/dakera/README.md with full component documentation.

[CLAassistant]

All committers have signed the CLA.

[ferhimedamine]

I have read the CLA Document and I hereby sign the CLA

[ferhimedamine]

Fixed the test-api-reference-build CI failure — the hatch run docs command was failing with docs: not found because:

1. haystack-pydoc-tools was missing from [tool.hatch.envs.default] dependencies
2. The docs script was missing from [tool.hatch.envs.default.scripts]
3. pydoc/config_docusaurus.yml did not exist

Added all three in the latest commit, following the pattern from integrations/anthropic/pyproject.toml.

[ferhimedamine]

I have read the CLA Document and I hereby sign the CLA

[julian-risch]

Hi @ferhimedamine thank you for opening this PR and for your patience! There are a couple of smaller issues with the PR that block us from merging it and releasing the integration. Could you please update the PR and address the following issues please?

• test_to_dict_round_trip will fail in CI because the store fixture uses Secret.from_token("test-key"). Should be Secret.from_env_var("DAKERA_API_KEY", strict=False) instead
• The code examples in the README all have errors and can't be run. (import paths, ...)
• Tests are not running because there is no workflow file

I recommend to have a look at integrations/mem0 as an example and potentially use our scaffolding script, which will generate the workflow file automatically for you and also the missing LICENSE.txt: https://github.com/deepset-ai/haystack-core-integrations/blob/main/CONTRIBUTING.md#create-a-new-integration

[ferhimedamine]

Thanks for the thorough review, @julian-risch — all three points are addressed, and I took the integrations/mem0 layout as the reference as you suggested.

1. test_to_dict_round_trip failing in CI
The store fixture now uses Secret.from_env_var("DAKERA_API_KEY", strict=False) instead of Secret.from_token(...), so to_dict()/from_dict() serialize cleanly. The fixture sets the env var via monkeypatch so the test is self-contained.

2. README examples
The usage example was broken — wrong import paths, a store= kwarg that doesn't exist, and run() arguments that didn't match the components. It's been rewritten and now reflects the real API:

• from haystack_integrations.memory_stores.dakera import DakeraMemoryStore
• from haystack_integrations.components.retrievers.dakera import DakeraMemoryRetriever
• from haystack_integrations.components.writers.dakera import DakeraMemoryWriter
• components take memory_store=...; writer.run(messages=...) / retriever.run(query=...)

The configuration table now lists the actual constructor parameters, and I added a Contributing section.

3. Tests not running (no workflow)
Added .github/workflows/dakera.yml (modeled on mem0.yml) plus the missing LICENSE.txt, and wired the integration into labeler.yml, CI_coverage_comment.yml, and the root README table. pyproject.toml gained the test hatch env and the ruff/mypy/coverage/pytest config that back fmt-check, test:types, and test:unit-cov-retry.

While making CI green I also caught and fixed two real bugs:

• Haystack's structlog logger rejects %-style positional args, so every logger.* call now uses {}-placeholders with keyword args (previously raised TypeError at runtime in the writer/retriever paths).
• Added py.typed markers so hatch run test:types (mypy) passes, and guarded base_url resolution against a None env value.

CI is now green across the full matrix (Python 3.10 & 3.14 on Linux, Windows, and macOS): https://github.com/deepset-ai/haystack-core-integrations/actions/runs/30078491113 — fmt-check, mypy, and 11 unit tests at 99% coverage.

Ready for another look whenever you have a moment. 🙏

[julian-risch]

@ferhimedamine Thanks for addressing the review. Unfortunately, there are still a number of inconsistencies, for example:

• PR body: docker run -p 3000:3000 vs. README & code default: port 3300
• Untyped output socket. integrations/dakera/src/haystack_integrations/components/retrievers/dakera/retriever.py#L722 uses @component.output_types(memories=list). mem0's equivalent uses list[ChatMessage]. A bare list weakens pipeline connection type-checking.
• integration tests should be added

[ferhimedamine]

@ferhimedamine Thanks for addressing the review. Unfortunately, there are still a number of inconsistencies, for example:

• PR body: docker run -p 3000:3000 vs. README & code default: port 3300
• Untyped output socket. integrations/dakera/src/haystack_integrations/components/retrievers/dakera/retriever.py#L722 uses @component.output_types(memories=list). mem0's equivalent uses list[ChatMessage]. A bare list weakens pipeline connection type-checking.
• integration tests should be added

Thx for feedback @julian-risch , i will adress all reported issues

[ferhimedamine]

Thanks @julian-risch — all three points are addressed, and I did a deeper audit against the Dakera server itself rather than just patching the docs. That surfaced that the client was targeting endpoints/a port that don't actually exist, so I corrected the whole API surface:

1. Port inconsistency (3000 vs 3300)
The server's default REST port is 3000 (DAKERA_PORT, EXPOSE 3000 in the image, and the dakera-deploy compose all agree). 3300 was the bug — the code default, README, and PR body now all use 3000 consistently.

2. Untyped output socket
DakeraMemoryRetriever now declares @component.output_types(memories=list[ChatMessage]) and returns recalled memories as system-role ChatMessage objects (Dakera fields — id, score, importance, … — under each message's meta), mirroring integrations/mem0. DakeraMemoryWriter now accepts list[ChatMessage] as input, so both ends type-check cleanly in a pipeline.

3. Integration tests
Added tests/test_integration.py (marked integration, skipped unless DAKERA_API_URL points at a live server) covering a store→recall round trip and the component pair, and re-enabled the integration step in the workflow.

Additional correctness fixes from the audit (these were real bugs):

• Endpoints: create is POST /v1/memory/store and recall is POST /v1/memory/recall. The previous /v1/memories and /v1/memories/search don't exist on the server and would have 404'd.
• Auth: the client now sends X-API-Key (the server's default header; Bearer is also accepted).
• Schema: the identity field is agent_id (required) — I removed the non-existent user_id; recall responses are parsed from memories[] where each item is {memory: {...}, score}.

CI is green across the full matrix (Python 3.10 & 3.14 on Linux, Windows, macOS), including the docs build and the new integration step: https://github.com/deepset-ai/haystack-core-integrations/actions/runs/30109488066 — ruff, mypy, 13 unit tests at 93% coverage.

Ready for another look. 🙏

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​dakera@​0.12.12

View full report

[ferhimedamine]

Heads-up on a consolidation, @julian-risch: we had two open PRs for Dakera — this one (#3515, the memory integration) and #3519 (the document-store integration). Since both were building the same dakera-haystack package in integrations/dakera/, only one can own that path — so I've merged the document-store work into this PR and am closing #3519 as redundant.

dakera-haystack now ships both, sharing one Dakera server:

• Memory — DakeraMemoryStore / DakeraMemoryRetriever / DakeraMemoryWriter (decay-weighted ChatMessage memory).
• Document store — DakeraDocumentStore (sync + async) + DakeraEmbeddingRetriever (dense retrieval with metadata filtering), via the official dakera Python SDK.

All of your review feedback from both PRs is incorporated:

• from feat: add dakera-haystack integration — self-hosted memory & document store for Haystack #3515: the Secret.from_env_var fixture fix, corrected README, and the CI workflow;
• from feat: add Dakera document store integration #3519: async unit tests for every async method, the _dakera_content reserved metadata key (so user metadata isn't clobbered), and the CountDocumentsTest/DeleteDocumentsTest/WriteDocumentsTest mixins.

CI is green across the matrix (Python 3.10 & 3.13 on Linux/Windows/macOS), including the docs build: https://github.com/deepset-ai/haystack-core-integrations/actions/runs/30113924150 — ruff, mypy over all packages, 74 unit tests at 91% coverage; integration tests are skipped in CI (no live server).

The updated PR description above reflects the unified package. Ready for another look — thanks for the thorough reviews on both PRs. 🙏

[julian-risch]

Hi @ferhimedamine and thanks again for opening this PR! I recommend to publish this integration yourselves under https://github.com/Dakera-AI similar to your other framework integration(s). We do have a repository template that you could use for that: https://github.com/deepset-ai/custom-component

To support you with the integration, I'd like to share a couple changes that are still required to make this new integration work well in your own repo:

• Copyright headers assign the code to Dakera AI. That works in your repo so you can leave that as is there but not in haystack-core-integrations.
• Four empty init.py files break haystack_integrations as a namespace package. Similarly, that will work differently in your own repo.
• dakera[async] extra is not declared although async_client.py raises ImportError: httpx is required for AsyncDakeraClient. Install it with: pip install dakera[async].
• Two different env vars for the same server URL: DAKERA_API_URL / DAKERA_URL
• Integration tests
• test_document_integration.py uses only CountDocumentsTest, DeleteDocumentsTest, WriteDocumentsTest. Missing from haystack.testing.document_store: FilterDocumentsTest, DocumentStoreBaseTests, DocumentStoreBaseExtendedTests, and the async part: haystack.testing.document_store_async provides CountDocumentsAsyncTest, WriteDocumentsAsyncTest, FilterDocumentsAsyncTest, DeleteDocumentsAsyncTest
• LOGICAL_OPERATORS = {"AND": "$and", "OR": "$or"} is missing NOT but docstrings imply it's supported
• Hand-written CHANGELOG.md: this file get generated. no need to add it manually.
• The memory store diverges from existing mem0 conventions, for example doesn't use deserialize_secrets_inplace, warm_up() and client property, keyword-only arguments, ...

Thanks again for your efforts and good luck with setting up the integration under https://github.com/Dakera-AI!

[ferhimedamine]

@julian-risch thx for comment and review, just curious what changed your mind , we were reviewing / working on the internal integration, now the recommendation is external integration

[julian-risch]

It's a better fit with your other framework integrations. :)