chore(modules): re-pin the memory module to tinymemory v1.15.2 - #6056
Conversation
v1.15.2 carries tinyhumansai/tinymemory#144, which makes `MemoryMaintenance::backfill_connector_trees` ask the ingest gate before it charges its limit. Against 1.15.1 the walk re-examines the same `limit` already-filed documents on every call and never reaches the rest, which is why the Sources page's "Repair older memories" button reports "Filed 0 (500 already there). More remain." forever (tinyhumansai#6051). Nothing in the host changes: the button, the RPC and the wire types are the same, and the numbers they show become honest once the module behind them moves. A patch bump: no contract member was added. The release also carries tinyhumansai/tinymemory#143 (the remote API), which touches nothing the host pins. Four pins move together, as they must: - `vendor/tinymemory` -> the v1.15.2 commit (258d9e5 -> 9143fe1) - the registry descriptor: version, release_url, and all 11 platform assets with the checksums the release published - `ARTIFACT_CAPABILITIES_PIN` - `memory_version` / `memory_sha256` in ci-full.yml, ci-lite.yml and e2e-reusable.yml (4 sites), which pin the ubuntu-22.04-x86_64 archive independently of the registry Verified rather than assumed: v1.15.2 has tinyhumansai#144's merge (f1c234b) as an ancestor; all 11 checksums were taken from the release's own checksum.toml with each archive name and its digest rewritten as one unit; `git diff v1.15.1..v1.15.2 -- crates/tinymemory-api/src/capabilities.rs` is empty, so the advertised family list is unchanged; both Cargo.lock files resolve `--locked` against the new checkout; and the two pin tests (`the_capability_list_matches_the_pinned_release`, `the_ci_workflows_pin_the_same_module_digest_as_the_registry`) pass. Refs tinyhumansai#6051
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe change updates TinyMemory from 1.15.1 to 1.15.2 across module metadata, the vendored submodule, and CI/E2E download pins. Platform archive checksums and workflow verification checksums are updated. ChangesTinyMemory release update
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to TinyMemory is updated to v1.15.2, delivering the backfill fix while keeping host interfaces and capabilities unchanged. No current merge-blocking risk is established. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
How this change flows0 changed behaviours across 3 relationships. 3 surrounding behaviours are shown (60 graph nodes walked). 41 further behaviours left out to keep the diagram readable. flowchart LR
n0["proxy"]:::impacted
n1["install_host_callbacks"]:::impacted
n2["Result"]:::impacted
n0 -->|calls| n1
n0 -->|uses| n2
n1 -->|uses| n2
classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff
Green: changed behaviour. Grey: surrounding behaviour. Arrows name the call, use, implementation, or test relationship. Orange: has findings. Red: has a finding that blocks the merge. |
![tinysweeper[bot]](https://avatars.githubusercontent.com/in/4526585?s=60&v=4){kind=small}
tinysweeper
Bot
added
the
priority: p3
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
…-tinymemory-1.15.2\n\nchore(modules): re-pin the memory module to tinymemory v1.15.2\n
1 participant
Summary
tinymemorymodule to v1.15.2 everywhere the host names it: theTINYMEMORYregistry record (version,release_url, all 11 platform archives with digests taken verbatim from the release'schecksum.toml),ARTIFACT_CAPABILITIES_PINinmodules/memory_part_01.rs, and the fourmemory_version/memory_sha256blocks inci-full.yml,ci-lite.ymlande2e-reusable.yml.vendor/tinymemoryto the tag commit9143fe1so the source-level seams match what the prebuilt module was built from.vendor/tinycortexis unchanged (v1.15.2 pins the same tinycortex commit as v1.15.1).git diff v1.15.1..v1.15.2 -- crates/tinymemory-api/src/capabilities.rsis empty, so only the pin moves.Problem
Ships the fix for #6051. The Sources page's Repair older memories button reported
Filed 0 into the memory tree (500 already there, 0 skipped). More remain.on every click after the first. The walk behind it (MemoryMaintenance::backfill_connector_trees, in the module) charged its per-call limit before the ingest gate could say a document was already filed, and it lists documents newest first — exactly the ones the post-#6007 sync path had already treed — so on any profile with more than 500 already-filed documents it re-examined the same 500 forever and never reached the pre-migrationskill-{toolkit}records the button exists for. The host half (button, RPC, wire types, strings) is correct as it stands; only the module behind it had to move.Solution
Move the pin. v1.15.2 brings tinyhumansai/tinymemory#144: the walk asks the ingest gate first, through the funnel's own identity derivation; a document the tree already holds is reported under
already_presentand costs none of the limit, only documents that still need reading and filing are charged, and the dry run counts the same way — so the confirmation modal's "Up to N" is the number still waiting andscanned: 0is the existing "Nothing to repair" toast. The wire shape is unchanged (scannednarrows from "examined" to "charged"). The release also carries tinyhumansai/tinymemory#143 (remote API), which touches nothing the host pins.Verified on a copy of the reporting profile with the patched module walk: two default-limit passes filed 500 + 458 documents, and the following dry run read
scanned 0, already_present 1580.Submission Checklist
backfill_tests.rs,engine/sync_tests.rs, module door test) and the existingmodules::memory_testspin assertions cover the host side (the_capability_list_matches_the_pinned_release,the_ci_workflows_pin_the_same_module_digest_as_the_registry— both green)Closes #6051belowImpact
tinymemory-module-1.15.2-<host>and verifies its digest. Repair older memories then converges: each click files up to 500 documents still waiting, and the button reports "Nothing to repair" once none are. No migration: the store schema is unchanged.skill-namespace as ambiguous (by design since feat(memory): backfill connector memories into the memory tree #6015); the reason lands in the response'snotes, which the UI does not surface. Follow-up to be filed.Run by hand:
node scripts/ci/check-openhuman-rust-layout.mjs,node scripts/ci/check-module-pins.mjs,cargo metadata --lockedforCargo.tomlandapp/src-tauri/Cargo.toml,cargo fmt -p openhuman -- --check,cargo test -p openhuman --lib -- modules::memory(38 passed),cargo check -p openhuman --features "$(bash scripts/ci/product-features.sh)".Related
AI Authored PR Metadata (required for Codex/Linear PRs)
Linear Issue
Commit & Branch
chore/repin-tinymemory-1.15.2Summary by CodeRabbit