raymondj99/openmemory - CodSpeed

openmemory

Blog Docs Changelog

Performance History

Latest Results

fix(embed): extract macOS ONNX Runtime tarballs (`./` prefix) (#24) `openmemory model download` shipped in v0.3.2 with bundled ONNX Runtime install. The tar extractor matched entries by string prefix against `<archive_root>/lib/`, but macOS ONNX Runtime tarballs prefix every entry with `./` while Linux ones do not, so on macOS the matcher dropped every entry. The install dir ended up empty, `ensure_dylib_symlink` then wrote a broken `libonnxruntime.dylib` symlink, and the post-check fired with `extraction completed but ...libonnxruntime.1.20.0.dylib is missing`. `extract_lib_subtree` now strips a leading `./` from each entry before comparing the prefix. `ensure_dylib_symlink` switches its "already installed?" check from `Path::exists` (which follows symlinks and reports false for a broken one) to `Path::symlink_metadata`, so a broken symlink left over from a prior failed run no longer poisons retries with EEXIST. Two new tests build synthetic tarballs that mirror the upstream Linux and macOS layouts (real versioned dylib + unversioned symlink in `lib/`, unrelated entry in `include/`) and assert that both extract correctly and the include subtree is skipped. A third test pre-seeds a broken symlink and confirms `ensure_dylib_symlink` is a no-op rather than a hard error. Verified end-to-end on macOS by running `openmemory model download` into a clean home directory: 25 MB versioned dylib, dSYM, and unversioned symlink all land under `<home>/runtime/onnxruntime-osx-arm64-1.20.0/lib/`. Linux remains unaffected because the new matcher is a strict superset of the old (strip `./` if present, otherwise leave the path unchanged); the new Linux-style test guards against regression. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

main

1 day ago

fix(embed): extract macOS ONNX Runtime tarballs (`./` prefix) `openmemory model download` shipped in v0.3.2 with bundled ONNX Runtime install. The tar extractor matched entries by string prefix against `<archive_root>/lib/`, but macOS ONNX Runtime tarballs prefix every entry with `./` while Linux ones do not, so on macOS the matcher dropped every entry. The install dir ended up empty, `ensure_dylib_symlink` then wrote a broken `libonnxruntime.dylib` symlink, and the post-check fired with `extraction completed but ...libonnxruntime.1.20.0.dylib is missing`. `extract_lib_subtree` now strips a leading `./` from each entry before comparing the prefix. `ensure_dylib_symlink` switches its "already installed?" check from `Path::exists` (which follows symlinks and reports false for a broken one) to `Path::symlink_metadata`, so a broken symlink left over from a prior failed run no longer poisons retries with EEXIST. Two new tests build synthetic tarballs that mirror the upstream Linux and macOS layouts (real versioned dylib + unversioned symlink in `lib/`, unrelated entry in `include/`) and assert that both extract correctly and the include subtree is skipped. A third test pre-seeds a broken symlink and confirms `ensure_dylib_symlink` is a no-op rather than a hard error. Verified end-to-end on macOS by running `openmemory model download` into a clean home directory: 25 MB versioned dylib, dSYM, and unversioned symlink all land under `<home>/runtime/onnxruntime-osx-arm64-1.20.0/lib/`. Linux remains unaffected because the new matcher is a strict superset of the old (strip `./` if present, otherwise leave the path unchanged); the new Linux-style test guards against regression. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

fix/macos-ort-extraction

1 day ago

docs(graph): fix stale MemoryError::NotFound link in add_relation (#23) CI's `cargo doc --workspace --no-deps -D warnings` job rejected the v0.4.0 commit because the `add_relation` docstring referenced `MemoryError::NotFound`, a non-existent variant. The actual variant is `MemoryError::EntityNotFound` — caught in code review when I adjusted the implementation, missed in the docstring. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

main

3 days ago

docs(graph): fix stale MemoryError::NotFound link in add_relation CI's `cargo doc --workspace --no-deps -D warnings` job rejected the v0.4.0 commit because the `add_relation` docstring referenced `MemoryError::NotFound`, a non-existent variant. The actual variant is `MemoryError::EntityNotFound` — caught in code review when I adjusted the implementation, missed in the docstring. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

fix/rustdoc-link

3 days ago

chore(release): v0.4.0 (#22) Two new MCP tools that close the post-hoc curator gap, plus a documentation fix on the `openmemory_remember` idempotency contract. * `openmemory_add_relation` attaches a relation between two existing entities resolved by `(name, type)`. Previously the only way to add an edge was through `openmemory_remember`, which forced callers to write a dummy observation just to attach a relation. `supersedes` / `clarifies` / `depends_on` curator flows now have a first-class surface. Missing entities surface as typed `-32004` errors rather than being silently created. * `openmemory_promote_observation` moves an observation between `memory_tier` values (`episodic` <-> `semantic` <-> `procedural`) without rewriting content. Enables the episodic-on-write, promote-on-consolidation lifecycle the curator policy assumes. Unknown or tombstoned ids return `{ modified: false }` rather than erroring. * `openmemory_remember`'s tool description now spells out the append-only contract: observations are NEVER deduplicated at write time; run `openmemory_consolidate` for periodic dedup, or `openmemory_recall` the proposed title first to skip the write on a high-scoring hit. Relations follow the same contract. Workspace test count: 591 pass / 0 fail. The `MemoryStore::add_relation` and `MemoryStore::set_observation_memory_tier` methods back the two new tools; their input validation rejects empty relation types, self-loop edges, and missing observation ids with typed errors. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

main

3 days ago

chore(release): v0.4.0 Two new MCP tools that close the post-hoc curator gap, plus a documentation fix on the `openmemory_remember` idempotency contract. * `openmemory_add_relation` attaches a relation between two existing entities resolved by `(name, type)`. Previously the only way to add an edge was through `openmemory_remember`, which forced callers to write a dummy observation just to attach a relation. `supersedes` / `clarifies` / `depends_on` curator flows now have a first-class surface. Missing entities surface as typed `-32004` errors rather than being silently created. * `openmemory_promote_observation` moves an observation between `memory_tier` values (`episodic` <-> `semantic` <-> `procedural`) without rewriting content. Enables the episodic-on-write, promote-on-consolidation lifecycle the curator policy assumes. Unknown or tombstoned ids return `{ modified: false }` rather than erroring. * `openmemory_remember`'s tool description now spells out the append-only contract: observations are NEVER deduplicated at write time; run `openmemory_consolidate` for periodic dedup, or `openmemory_recall` the proposed title first to skip the write on a high-scoring hit. Relations follow the same contract. Workspace test count: 591 pass / 0 fail. The `MemoryStore::add_relation` and `MemoryStore::set_observation_memory_tier` methods back the two new tools; their input validation rejects empty relation types, self-loop edges, and missing observation ids with typed errors. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

chore/release-v0.4.0

3 days ago

chore(release): v0.3.3 (#21) Hotfix on top of v0.3.2: the new ONNX Runtime bundling installs the shared library under `<home>/runtime/onnxruntime-<ver>/`, but the CLI's startup hook resolved `<home>` from `OPENMEMORY_HOME` / `~/.openmemory` only, not from the `--home` flag. Spawning `openmemory --home X mcp` from an integrating tool (e.g. the omdemos curator) therefore missed the install and panicked with `cannot open shared object file: libonnxruntime.so` on the first vector-mode call. The startup hook now scans argv for `--home <path>` / `--home=<path>` and promotes the value into `OPENMEMORY_HOME` before the embed crate's `Config::home_dir()` resolves. User-set `OPENMEMORY_HOME` and `ORT_DYLIB_PATH` still take precedence. Verified end-to-end against the demo VM: `omdemos check --mode vector` now passes 11/11 retrieval checks on a clean install with no manual `LD_LIBRARY_PATH` or symlink plumbing. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

main

3 days ago

chore(release): v0.3.3 Hotfix on top of v0.3.2: the new ONNX Runtime bundling installs the shared library under `<home>/runtime/onnxruntime-<ver>/`, but the CLI's startup hook resolved `<home>` from `OPENMEMORY_HOME` / `~/.openmemory` only, not from the `--home` flag. Spawning `openmemory --home X mcp` from an integrating tool (e.g. the omdemos curator) therefore missed the install and panicked with `cannot open shared object file: libonnxruntime.so` on the first vector-mode call. The startup hook now scans argv for `--home <path>` / `--home=<path>` and promotes the value into `OPENMEMORY_HOME` before the embed crate's `Config::home_dir()` resolves. User-set `OPENMEMORY_HOME` and `ORT_DYLIB_PATH` still take precedence. Verified end-to-end against the demo VM: `omdemos check --mode vector` now passes 11/11 retrieval checks on a clean install with no manual `LD_LIBRARY_PATH` or symlink plumbing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

chore/release-v0.3.3

3 days ago

Latest Branches

0%

fix(embed): extract macOS ONNX Runtime tarballs (`./` prefix)#24

1 day ago

3b21e25

fix/macos-ort-extraction

0%

docs(graph): fix stale MemoryError::NotFound link in add_relation#23

3 days ago

fb5e649

fix/rustdoc-link

0%

chore(release): v0.4.0#22

3 days ago

e84d506

chore/release-v0.4.0

© 2026 CodSpeed Technology

Home Terms Privacy Docs