Skip to content

test(memoryOps): stop the memory-op tests writing into the real machine-wide index - #8

Merged
TheArchitectit merged 1 commit into
TheArchitectit:masterfrom
davidj4tech:fix/test-index-isolation
Jul 29, 2026
Merged

test(memoryOps): stop the memory-op tests writing into the real machine-wide index#8
TheArchitectit merged 1 commit into
TheArchitectit:masterfrom
davidj4tech:fix/test-index-isolation

Conversation

@davidj4tech

Copy link
Copy Markdown
Contributor

The leak

applyMemoryOps() mirrors every write into the machine-wide PGlite memory index
via the fire-and-forget indexMemoryWrite()upsertMemoryEmbedding(), keyed by
repoKey(stateDir). For this file's tmp state dirs that key is the tmp path
itself, so running src/memoryOps.test.ts writes rows into the developer's real
~/.pi/mega-compact-vector:

/tmp/mc-memops-w3XL9J/add      "we use node:sqlite as the store"
/tmp/mc-memops-w3XL9J/dup      "threshold is 50k"
/tmp/mc-memops-w3XL9J/replace  "the threshold is 100k"

They persist, and they are reachable. Cross-repo recall is on by default
(crossRepoEnabled: true), recallMemoriesCrossRepo() searches the global index
with no repo filter, and the floor it uses is opts.crossRepoCosine ?? 0.3
no caller sets it, so the strict crossRepoCosine: 0.90 from config never reaches
this path (it is passed as dedupSim in extensions/mega-pipeline/recall.ts).

So a live session in an unrelated project can be handed a stale test assertion as
if it were another project's memory — including the contradictory 50k/100k pair.
This was found on a real machine whose index held 33 such rows and nothing
else
: every entry available to cross-repo recall was test junk.

scripts/run-tests.mjs already sets MEGACOMPACT_INDEX_DIR per child, so the
suite was never the leak — invoking the file directly was, which is exactly what
one does while debugging.

The change

Disables PGlite for the file — the same guard memoryRoundtrip.test.ts already
uses for the same reason, since these suites exercise the sync node:sqlite path
only — and points MEGACOMPACT_INDEX_DIR at the per-run tmp dir so the isolation
still holds if a later test re-enables the index.

Verification

live-index rows added result
current code, one run 3 9/9 pass in 11s
this change, three consecutive runs 0 9/9 pass in <1s each

The file also stops emitting "asynchronous activity after the test ended" — with
a per-run index dir, an initdb was still running when the first test finished.

Purely test-side; no src/ behavior change.

…ne-wide index

applyMemoryOps() mirrors every write into the machine-wide PGlite memory
index via the fire-and-forget indexMemoryWrite() → upsertMemoryEmbedding(),
keyed by repoKey(stateDir). For this file's tmp state dirs that key is the
tmp path itself, so running the file wrote rows like

  /tmp/mc-memops-w3XL9J/add  "we use node:sqlite as the store"
  /tmp/mc-memops-w3XL9J/dup  "threshold is 50k"
  /tmp/mc-memops-w3XL9J/replace  "the threshold is 100k"

into the developer's real ~/.pi/mega-compact-vector. They persist, and
cross-repo recall is enabled by default and searches the global index with
no repo filter (src/recall.ts falls back to a 0.3 cosine floor), so a live
session in an unrelated project can be handed a stale test assertion — the
contradictory 50k/100k pair included — as if it were another project's
memory. Found on a real machine holding 33 such rows and nothing else.

scripts/run-tests.mjs already sets MEGACOMPACT_INDEX_DIR per child, so the
suite was never the leak; invoking the file directly was.

Disables PGlite for the file (the same guard memoryRoundtrip.test.ts uses,
for the same reason — these suites exercise the sync node:sqlite path only)
and points MEGACOMPACT_INDEX_DIR at the per-run tmp dir so the isolation
still holds if a later test re-enables the index.

Verified: on the current code a run adds 3 rows to the live index; with
this change three consecutive runs add none. The file also gets faster and
quieter — 9/9 in <1s instead of 11s, with no "asynchronous activity after
the test ended" from an initdb still running past the first test.
@gemini-code-assist

Copy link
Copy Markdown

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

@TheArchitectit
TheArchitectit merged commit ecab4af into TheArchitectit:master Jul 29, 2026
0 of 2 checks passed
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