7.28 + cortex 2.5 fails to initialize against existing on-disk data (setConnectionsCodec is not a function) #3

New issue

Closed

opened 2026-05-29 22:40:20 +02:00 by dpsifr · 3 comments

dpsifr commented

2026-05-29 22:40:20 +02:00

(Migrated from github.com)

Brainy 7.28 / Cortex 2.5 fails to initialize against existing on-disk data

Symptom

Every RPC against an existing user brain (data written by Brainy ≤ 7.27 / Cortex ≤ 2.4) fails. Production trace from Memory service v0.2.17 on Bun 1.3:

[brainy] Re-acquiring writer lock for /opt/memory/data/memory/users/3ea8e856…
         held by the same process (PID 628929). If you intended to keep the
         previous Brainy instance alive, this is a bug — close it first.
[brainy] mmap-vector backend not wired (Capacity must be > 0); falling back to
         per-entity vector reads
[SDK/router] resolveBrain failed for memory.updateProfile:
         Failed to initialize Brainy:
         TypeError: this.index.setConnectionsCodec is not a function.
         (In 'this.index.setConnectionsCodec(codec)',
          'this.index.setConnectionsCodec' is undefined)

User cannot read or write anything — every method goes through resolveBrain → init failure.

Versions

@soulcraft/brainy 7.28.0 (latest on npm, 2026-05-28)
@soulcraft/cortex 2.5.0 (latest on npm, 2026-05-28)
Bun 1.3.11
Linux x64 (Debian-based GCE VM)
Storage type: Cortex mmap-filesystem
Data dir: created Apr 3 2026 by a much earlier Brainy/Cortex (probably 7.20–7.22 era)

What we tried

Cleared bun.lockb + bun install --production on the VM → same.
Same code, same VM, fresh process restart → identical trace every time the first RPC for that user lands.
Memory's pool wraps Brainy via Cortex's mmap-filesystem storage, scoped per-tenant by sha256(email) (one Brainy per user).

Re-acquiring writer lock … held by the same process — sounds like the pool is constructing a second Brainy for the same tenant before the first one is closed, or Brainy is internally re-acquiring without releasing. The "this is a bug — close it first" message implies Brainy itself believes this is illegal.
mmap-vector backend not wired (Capacity must be > 0) — Cortex's mmap vector store reports zero capacity when initializing against the existing on-disk segments. Possibly a format/version mismatch with files written by older Cortex.
this.index.setConnectionsCodec is not a function — the actual exception. setConnectionsCodec appears to be expected on this.index during the codec configuration step of init. Either an HNSW codec method that Brainy 7.28 expects Cortex 2.5 to expose (or vice versa), or a method that's defined only on one of two index implementations and Brainy is dispatching to the wrong one when loading existing data.

If you point me at where setConnectionsCodec should live, I can run a focused repro against just an existing user dir.

What works

A fresh user with no existing on-disk data has not been tested yet (about to). If a fresh brain initialises cleanly, this is specifically a backward-compat issue with on-disk data written by older versions — the same shape of issue as the R5 follow-up.

Repro asset

I can tar up one of the affected user dirs from the VM if it would help. They contain only test-time content (no real PII), but I'd rather hand it over via a private channel than attach to this issue.

Impact

Memory v0.2.17 is currently unable to serve any user who tested in March/April 2026. Workshop's Muse integration depends on this and is effectively blocked.

Asks

Confirm whether Brainy.create({ storage: mmapFilesystem(…) }) against an existing 7.22-era dir is a supported upgrade path, or if a migration step is required.
If yes, diagnose the setConnectionsCodec undefined call — which side owns the codec method.
If a migration is required, expose a brainy migrate CLI command or a documented one-shot script.

# Brainy 7.28 / Cortex 2.5 fails to initialize against existing on-disk data ## Symptom Every RPC against an existing user brain (data written by Brainy ≤ 7.27 / Cortex ≤ 2.4) fails. Production trace from Memory service v0.2.17 on Bun 1.3: ``` [brainy] Re-acquiring writer lock for /opt/memory/data/memory/users/3ea8e856… held by the same process (PID 628929). If you intended to keep the previous Brainy instance alive, this is a bug — close it first. [brainy] mmap-vector backend not wired (Capacity must be > 0); falling back to per-entity vector reads [SDK/router] resolveBrain failed for memory.updateProfile: Failed to initialize Brainy: TypeError: this.index.setConnectionsCodec is not a function. (In 'this.index.setConnectionsCodec(codec)', 'this.index.setConnectionsCodec' is undefined) ``` User cannot read or write anything — every method goes through `resolveBrain` → init failure. ## Versions - `@soulcraft/brainy` 7.28.0 (latest on npm, 2026-05-28) - `@soulcraft/cortex` 2.5.0 (latest on npm, 2026-05-28) - Bun 1.3.11 - Linux x64 (Debian-based GCE VM) - Storage type: Cortex `mmap-filesystem` - Data dir: created Apr 3 2026 by a much earlier Brainy/Cortex (probably 7.20–7.22 era) ## What we tried - Cleared `bun.lockb` + `bun install --production` on the VM → same. - Same code, same VM, fresh process restart → identical trace every time the first RPC for that user lands. - Memory's pool wraps Brainy via Cortex's `mmap-filesystem` storage, scoped per-tenant by `sha256(email)` (one Brainy per user). ## Three things in one trace — likely related 1. **`Re-acquiring writer lock … held by the same process`** — sounds like the pool is constructing a second Brainy for the same tenant before the first one is closed, *or* Brainy is internally re-acquiring without releasing. The "this is a bug — close it first" message implies Brainy itself believes this is illegal. 2. **`mmap-vector backend not wired (Capacity must be > 0)`** — Cortex's mmap vector store reports zero capacity when initializing against the existing on-disk segments. Possibly a format/version mismatch with files written by older Cortex. 3. **`this.index.setConnectionsCodec is not a function`** — the actual exception. `setConnectionsCodec` appears to be expected on `this.index` during the codec configuration step of init. Either an HNSW codec method that Brainy 7.28 expects Cortex 2.5 to expose (or vice versa), or a method that's defined only on one of two index implementations and Brainy is dispatching to the wrong one when loading existing data. If you point me at where `setConnectionsCodec` should live, I can run a focused repro against just an existing user dir. ## What works A *fresh* user with no existing on-disk data has not been tested yet (about to). If a fresh brain initialises cleanly, this is specifically a backward-compat issue with on-disk data written by older versions — the same shape of issue as the R5 follow-up. ## Repro asset I can tar up one of the affected user dirs from the VM if it would help. They contain only test-time content (no real PII), but I'd rather hand it over via a private channel than attach to this issue. ## Impact Memory v0.2.17 is currently unable to serve any user who tested in March/April 2026. Workshop's Muse integration depends on this and is effectively blocked. ## Asks 1. Confirm whether `Brainy.create({ storage: mmapFilesystem(…) })` against an existing 7.22-era dir is a supported upgrade path, or if a migration step is required. 2. If yes, diagnose the `setConnectionsCodec` undefined call — which side owns the codec method. 3. If a migration is required, expose a `brainy migrate` CLI command or a documented one-shot script.

dpsifr commented

2026-05-29 22:41:14 +02:00

(Migrated from github.com)

Update: a FRESH user (no existing on-disk data) fails identically. Just curl-tested against the live VM:

$ curl -X POST https://memory.soulcraft.com/api/rpc \
    -H 'X-Service-Secret: …' -H 'X-User-Email: brain-ui-test@soulcraft.com' \
    -d '{"ns":"memory","method":"remember","args":["hello world",{}]}'

{"error":{"code":"BRAIN_UNAVAILABLE","message":"Cannot resolve brain for memory.remember: Failed to initialize Brainy: TypeError: this.index.setConnectionsCodec is not a function..."}}
HTTP 503

So this is not an upgrade-from-older-data issue. @soulcraft/brainy@7.28.0 + @soulcraft/cortex@2.5.0 cannot initialize a brain at all in our setup (mmap-filesystem storage, Bun 1.3, Linux x64). setConnectionsCodec is missing on this.index for every newly-created brain, not just legacy ones.

Memory is currently downgrading to a known-good pair to unblock production. Will report which pair works.

Update: a FRESH user (no existing on-disk data) fails identically. Just curl-tested against the live VM: ``` $ curl -X POST https://memory.soulcraft.com/api/rpc \ -H 'X-Service-Secret: …' -H 'X-User-Email: brain-ui-test@soulcraft.com' \ -d '{"ns":"memory","method":"remember","args":["hello world",{}]}' {"error":{"code":"BRAIN_UNAVAILABLE","message":"Cannot resolve brain for memory.remember: Failed to initialize Brainy: TypeError: this.index.setConnectionsCodec is not a function..."}} HTTP 503 ``` So this is **not** an upgrade-from-older-data issue. `@soulcraft/brainy@7.28.0` + `@soulcraft/cortex@2.5.0` cannot initialize a brain at all in our setup (mmap-filesystem storage, Bun 1.3, Linux x64). `setConnectionsCodec` is missing on `this.index` for every newly-created brain, not just legacy ones. Memory is currently downgrading to a known-good pair to unblock production. Will report which pair works.

dpsifr commented

2026-05-29 22:45:33 +02:00

(Migrated from github.com)

Bisect result:

7.24.0 + cortex 2.2.1 → ✅ works (fresh users + existing data)
7.27.0 + cortex 2.4.0 → ❌ same TypeError
7.28.0 + cortex 2.5.0 → ❌ same TypeError

Regression landed somewhere in the 7.25 → 7.27 / cortex 2.3 → 2.4 window (all published 2026-05-27 / 28). Memory pinned to 7.24.0 / 2.2.1 for now. Repro is just brain.add() against mmap-filesystem in distributed mode on a clean dir.

Bisect result: - 7.24.0 + cortex 2.2.1 → ✅ works (fresh users + existing data) - 7.27.0 + cortex 2.4.0 → ❌ same TypeError - 7.28.0 + cortex 2.5.0 → ❌ same TypeError Regression landed somewhere in the 7.25 → 7.27 / cortex 2.3 → 2.4 window (all published 2026-05-27 / 28). Memory pinned to 7.24.0 / 2.2.1 for now. Repro is just `brain.add()` against mmap-filesystem in distributed mode on a clean dir.

dpsifr commented

2026-05-30 02:01:19 +02:00

(Migrated from github.com)

Fixed in @soulcraft/cortex@2.5.1 (2026-05-29). Memory v0.2.22 deployed on brainy@7.28.0 + cortex@2.5.1; smoke-tested fresh-user remember+list, existing-user list, panel SSE — all green against memory.soulcraft.com. Thanks team.