Skip to content

fix(shared): let ArchivedMemories create its own table, and stop the test leaking - #86

Merged
Cipher208 merged 1 commit into
masterfrom
fix/archived-memories-needs-a-neighbour
Oct 7, 2026
Merged

Cipher208 merged 1 commit into
masterfrom
fix/archived-memories-needs-a-neighbour

Conversation

@Cipher208

Copy link
Copy Markdown
Owner

test_archived_memories failed with no such table: archived_memories when run alone, and passed when another test had migrated the shared session database first. A test that needs a neighbour to pass is testing the neighbour, not the class.

Two separate defects, one on each side.

The test wrote to the real memory directory

It built ArchivedMemories() with no connection manager, so it used the global one — and before hermetic_global_db existed (90c9149, 2026-08-24) that was the live data dir.

The evidence is still on disk: ~/.mcp-ariel-memory/memory.db holds 32 rows with user_id='test_sh', all of them from 2026-08-24 — the day the fixture landed. The fixture stopped further writes; it did not clean up the ones already there.

The test now takes its own manager on tmp_path, like its neighbour tests/test_shared/test_connection.py already did. test_dream_buffer and test_embedding_cache are given the same treatment: neither of them ever checked a global property either, and test_sh is the marker both of them use.

The class assumed its table already existed

archive() and get_archived() went straight to SELECT, while the table is created by _init_db() — and in production by the Alembic migration. On a migrated database it worked, which is exactly what hid the problem.

DreamBuffer solved the identical problem already, with an idempotent ensure() guarded by _ready and called from each method that touches the table. ArchivedMemories now does the same, with the same shape and for the same reason. The schema in _init_db matches the migration's definition exactly, so no new migration is needed.

This was reachable outside tests, not just inside them: four production call sites construct ArchivedMemories and never run migrations — core/episodic.py, lifecycle/forgetting.py, rag/conflict.py, mcp_server/tools/primitives/forget.py. Two others (features/compression.py, forget.py) called _init_db() by hand before archive(); those calls stay, now simply redundant rather than load-bearing.

Tests

  • Each of the six tests in the file passes alone — previously one failed alone.
  • One new test covers the class on an already-migrated database.
  • Full suite: 2087 passed.
  • The real memory directory was verified untouched: 32 rows, last write 2026-08-24 14:09:12, mtime unchanged.

…test leaking

`test_archived_memories` failed with `no such table: archived_memories` when
run alone, and passed when another test had migrated the shared session
database first. A test that needs a neighbour to pass is testing the
neighbour, not the class.

Two separate defects, one on each side.

**The test wrote to the real memory directory.** It built `ArchivedMemories()`
with no connection manager, so it used the global one — and before
`hermetic_global_db` existed (90c9149, 2026-08-24) that was the live data dir.
The evidence is still there: `~/.mcp-ariel-memory/memory.db` holds 32 rows with
`user_id='test_sh'`, all of them from 2026-08-24, the day the fixture landed.
It now takes its own manager on `tmp_path`, like its neighbour
`test_connection.py` already did. `test_dream_buffer` and `test_embedding_cache`
are given the same treatment: neither ever checked a global property, and the
leak date names `test_sh` as the marker for both.

**The class assumed its table already existed.** `archive()` and
`get_archived()` went straight to `SELECT`, while the table is created by
`_init_db()` — and in production by the Alembic migration. On a migrated
database it worked, which is what hid this. `DreamBuffer` solved the identical
problem already, with an idempotent `ensure()` guarded by `_ready` and called
from each method that touches the table; `ArchivedMemories` now does the same,
with the same shape and for the same reason. The schema in `_init_db` matches
the migration's definition exactly, so no new migration is needed.

Four production call sites construct `ArchivedMemories` and never run
migrations — `core/episodic.py`, `lifecycle/forgetting.py`, `rag/conflict.py`
and `mcp_server/tools/primitives/forget.py` — so this was reachable outside
tests, not just inside them. Two others (`features/compression.py`,
`forget.py`) called `_init_db()` by hand before `archive()`; those calls stay,
they are now simply redundant rather than load-bearing.

Tests: each of the six in the file passes alone (was: one failed alone); one
new test covers the class on an already-migrated database. Full suite: 2087
passed. The real memory directory was verified untouched — still 32 rows and
the same mtime.
@github-actions github-actions Bot added the fix label Oct 7, 2026
@coderabbitai

coderabbitai Bot commented Oct 7, 2026

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration
  • Configuration used: Repository: Cipher208/a-memory/.coderabbit.yaml
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: a44495e8-06a3-4539-a57e-6b471898bff1
  • Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@Cipher208
Cipher208 merged commit 5835182 into master Oct 7, 2026
19 checks passed
@Cipher208
Cipher208 deleted the fix/archived-memories-needs-a-neighbour branch October 7, 2026 14:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant