ci: update mem0ai requirement from <1.0.0,>=0.1.104 to >=0.1.104,<3.0.0

[dependabot]

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

---

Updates the requirements on mem0ai to permit the latest version.

Release notes

Sourced from mem0ai's releases.

Mem0 Python SDK (v2.0.14)

New Features:

• Vector Stores: Add an Oracle AI Vector Search provider (oracledb) with connection pooling, HNSW/IVF indexes, JSON metadata filtering, and six selectable distance metrics (#5358)

Bug Fixes:

• Vector Stores: Translate a "*" filter value in OpenSearch into an exists query for every key, not just identity keys. It was previously ignored or matched literally against the string "*", so a wildcard filter returned nothing (#6522)
• Vector Stores: Re-raise errors from OpenSearch search() instead of returning [], so a transport, auth, or index misconfiguration surfaces instead of looking like zero matches. keyword_search() still degrades on failure, since it is a best-effort BM25 signal (#6519)
• Vector Stores: Guard the text field in Milvus update() behind the _has_bm25_schema check, matching insert(), so updating a memory in a collection without the BM25 text/sparse schema no longer fails (#5705)

Commits

• b357a5a chore(release): Python SDK v2.0.14, TypeScript SDK v3.1.2 (#6589)
• d653b63 fix(milvus): guard text field in update() with _has_bm25_schema check (#5705)
• cc46715 fix(ts-oss/cassandra): apply every operator in a compound field filter (#6511)
• 01afdde salvage: fix(opensearch) re-raise search errors (credit @​yashwanth123 #6477) ...
• d6d89c9 Add Oracle Vector Store Integration (#5358)
• c2150e8 docs: SEO and AEO updates for the memory expiration page (#6535)
• 19c7bb8 fix(ts-oss/chroma): stop dropping filter conditions in where-clause translati...
• e6281ab fix(ts-oss): forward responseFormat to Gemini in generateResponse (#6468)
• a71d7bd fix(dashboard): clear the LLM API key on provider change (#6475)
• 56ec7d2 fix(vector_stores/opensearch): translate the '*' wildcard to an exists query ...
• Additional commits viewable in compare view

[mehtarac]

@strandly-the-agent is this safe to merge?

[mehtarac]

/strands review, is this safe to merge?

[strandly-the-agent]

No — I wouldn't merge this as-is. The widened range admits mem0ai 2.x, and a fresh install of the mem0-memory extra resolves 2.0.17, which breaks two of the mem0_memory tool's documented actions at runtime. The migration this bump presupposes is #483, which is open and already pins mem0ai>=2.0.0,<3.0.0 in both extras — if that lands, this PR is unnecessary.

Verified on c49f4ad, running mem0ai 2.0.17 against the current pin 0.1.118 side by side:

✅	pip install --dry-run "mem0ai>=0.1.99,<3.0.0" "opensearch-py>=2.8.0,<3.0.0" → mem0ai 2.0.17 (so this is not a no-op)
🔴	list and retrieve raise ValueError under 2.0.17; both are accepted under 0.1.118
⚠️	tests/test_mem0.py passes 23/23 under 2.0.17 — green CI is not evidence of safety here
✅	_verify_memory_ownership still works on 2.x — no tenant-isolation regression

🔴 list and retrieve break on both backends. mem0 2.x rejects top-level user_id/agent_id on get_all()/search() and requires filters={...}, but the tool passes them top-level at src/strands_tools/mem0_memory.py:458 and :465. That's reached straight from the documented tool actions (mem0_memory.py:952 → :458; mem0_memory.py:975 → :465), so agent.tool.mem0_memory(action="retrieve", query=...) fails every time on a fresh install — no unusual input needed.

🔴 The Neptune graph backends become silent no-ops. mem0 2.x's MemoryConfig has no graph_store field and pydantic ignores unknown keys, so the configs built at mem0_memory.py:316 (Neptune Database) and :407 (Neptune Analytics graph) are dropped with no error and no warning — graph relations just stop happening. #483 removes these paths deliberately; merging this bump alone leaves them in place, silently dead.

Suggested path: hold or close this in favour of #483 (its own pin supersedes this diff). If you'd rather unblock the bump independently, it needs the filters= rewrite plus a decision on the Neptune graph paths — which is exactly #483's scope.

Evidence — commands and output

1. What the range actually resolves to

$ pip install --dry-run "mem0ai>=0.1.99,<3.0.0" "opensearch-py>=2.8.0,<3.0.0"
total pkgs resolved: 37
  mem0ai -> 2.0.17
  opensearch-py -> 2.8.0

mem0ai 1.0.0 (2025-10-16) and 2.0.0 (2026-04-16) are both published; 2.0.17 is current. The dependency closure also grows a lot across the boundary — core requires_dist went from 15 entries in 0.1.104 to 56 in 2.0.17.

2. The break, end to end through the tool's own client

# mem0ai 2.0.17, tool's FAISS default backend, embedder/llm overridden to avoid needing AWS
c = Mem0ServiceClient(config=cfg)
c.list_memories(user_id="alice")             # -> action="list"
c.search_memories("pizza", user_id="alice")  # -> action="retrieve"

mem0ai version: 2.0.17
client backend: Memory
[ FAIL ] list     -> mem0.get_all(user_id=...)
         ValueError: Top-level entity parameters frozenset({'user_id', 'agent_id'}) are not supported in get_all(). Use filters={'user_id': '...'} instead.
[ FAIL ] retrieve -> mem0.search(user_id=...)
         ValueError: Top-level entity parameters frozenset({'user_id', 'agent_id'}) are not supported in search(). Use filters={'user_id': '...'} instead.

The guard is _reject_top_level_entity_params in mem0/memory/main.py, and the same check exists in the Platform client's MemoryClient.get_all / .search — so the MEM0_API_KEY path is affected too, not just the OSS backend. It fires before any network I/O, which is why this is reproducible offline.

3. A/B against the current pin (this is what makes it a regression rather than something pre-existing)

mem0 0.1.118
  Memory.get_all: (self, *, user_id=None, agent_id=None, run_id=None, filters=None, limit=100)
  Memory.search:  (self, query, *, user_id=None, agent_id=None, run_id=None, limit=100, filters=None, threshold=None)
[ OK ] list -> mem0.get_all(user_id=...)

Both parameters are explicitly part of the 0.1.x signature. (retrieve under 0.1.118 fails only with an OpenAI 401 from a deliberately fake key — i.e. it passed validation and reached a real embedding call.)

4. Why CI stays green

$ pytest tests/test_mem0.py -q     # under mem0ai 2.0.17
23 passed in 2.07s

tests/test_mem0.py:83 (and :491, :588) patch strands_tools.mem0_memory.Mem0Memory wholesale, with mock_mem0_memory.from_config.return_value = mock_client at :106, so a MagicMock accepts any signature and the real mem0 API is never exercised. The suite cannot distinguish two incompatible majors of the dependency it is testing.

5. graph_store

>>> MemoryConfig.model_fields.keys()
['vector_store', 'llm', 'embedder', 'history_db_path', 'reranker', 'version', 'custom_instructions']
>>> MemoryConfig.model_config.get("extra")   # default = ignore
>>> MemoryConfig(graph_store={...})          # accepted, then dropped
graph_store present in model_dump(): False

GraphFactory no longer exists in mem0.utils.factory. The neptune vector store provider does still exist in 2.x, so only the graph paths are affected.

Appendix — non-blocking (3)

• ⚪ Platform store may report success while storing nothing. mem0 2.0's release notes say Platform add is async by default and returns {status: "PENDING", event_id}. mem0_memory.py:918 normalises with results.get("results", []), which would yield [] — so action="store" would print nothing and return [] as the tool result while the write is still in flight. Not executed — I have no mem0 API key in the sandbox, so this one is read from the release notes and the code, not verified. Worth a look if the Platform backend matters to you.
• ⚪ Pre-existing, not this PR's problem: the test-mocking gap in item 4 above is true with ci: update mem0ai requirement from <1.0.0,>=0.1.104 to >=0.1.104,<3.0.0 #558 closed unmerged. Not filing an issue for it, since feat(mem0_memory)!: upgrade to mem0ai 2.x and remove Neptune graph backends #483 already adds tests_integ/test_mem0_memory_e2e.py covering the real CRUD cycle against mem0ai 2.x.
• ⚪ The floor stayed at >=0.1.104 / >=0.1.99, so the range now spans three majors and which one you get depends on the environment (fresh install → 2.x; an existing env → whatever is already there). I raised the same increase-if-necessary point on ci: update mypy requirement from <1.0.0,>=0.981 to >=0.981,<3.0.0 #556, so I won't re-litigate it here.

How this review ran

Triage routed this to the correctness and test-quality passes (skipping API/DevX, docs, LLM-context and issue-alignment — no public API, docs or model-facing text in the diff) and returned a no-go on the PR itself. The findings above are my own direct verification, reproduced with the commands shown. In the interest of not sitting on this any longer I cancelled the three specialist subagent passes (adversarial, correctness, test-quality) before they returned, so this is a single-context review rather than the usual independent fan-out — worth weighing if you want a second opinion. Everything here is reproducible from the commands above, and both findings match what #483's own description documents independently.