chore(modules): re-pin the memory module to tinymemory v1.13.8 - #6013
Merged
YellowSnnowmann merged 1 commit intoSep 3, 2026
Merged
Conversation
v1.13.8 carries tinyhumansai/tinymemory#134, which routes connector items into the memory-tree ingest funnel. Before it, a Composio sync wrote namespace documents and vector chunks but never `mem_tree_chunks`, so Gmail synced thousands of records while tree recall, the Memory Tree graph and the source row's ingest status all reported zero. This repo only dev-depends on `tinymemory-tinycortex` — the production engine ships inside the prebuilt TinyBus module — so that fix reaches nobody until the pin moves. Four pins move together, because any subset is a red intermediate state: - `vendor/tinymemory` -> the v1.13.8 commit (ded26ae -> c253e70) - the registry descriptor: version, release_url, and all 11 platform assets with the checksums published on the release - `ARTIFACT_CAPABILITIES_PIN`, which `the_capability_list_matches_the_pinned_release` compares against the registry - `memory_version` / `memory_sha256` in ci-full.yml, ci-lite.yml and e2e-reusable.yml, which pin the ubuntu-22.04-x86_64 archive independently (4 sites). `the_ci_workflows_pin_the_same_module_digest_as_the_registry` caught these; unfixed, CI downloads the 1.13.8 archive, checks it against the 1.13.7 digest and refuses it. Verified rather than assumed, since a pin aimed at the wrong build fails silently: v1.13.8 has the tinyhumansai#134 merge (f143a150) as an ancestor and carries `ingest_connector_item_tolerated` at the tag; all 11 checksums were generated from the release's own checksum.toml and cross-checked back against it, with each archive name and its digest rewritten as one unit so a name cannot end up beside the previous release's hash; and `git diff v1.13.7..v1.13.8 -- crates/tinymemory-api/src/capabilities.rs` is empty, so no family was added and only the pin string moves. Recovers nothing already on disk — the per-item sync gate treats ingested items as done, so existing records need the backfill tracked in tinyhumansai#6012. Refs tinyhumansai#6007
Contributor
|
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; 7 remain after this review. 📝 WalkthroughWalkthroughTinyMemory is updated from 1.13.7 to 1.13.8 across module metadata, platform artifact checksums, the vendored reference, and CI workflows. ChangesTinyMemory 1.13.8 upgrade
Estimated code review effort: 2 (Simple) | ~8 minutes Merge Risk: ⚪ Minimal · up to This updates TinyMemory to 1.13.8, enabling connector items to enter the memory-tree ingest path and ensuring corresponding cleanup on source removal. The module metadata, artifact pins, and CI download pins are aligned, with no active merge-readiness risk identified. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2 files. (4 skipped: 4 unsupported.) Comment |
YellowSnnowmann
marked this pull request as ready for review
September 3, 2026 17:01
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. |
![tinysweeper[bot]](https://avatars.githubusercontent.com/in/4526585?s=60&v=4){kind=small}
There was a problem hiding this comment.
tinysweeper found nothing blocking. Approving.
$0.0151 · 139,507 in / 3,442 out · 15,364 cached (11%) · openrouter/openai/text-embedding-3-small, deepseek/deepseek-v4-flash, z-ai/glm-5.2 · 1,012 embedded
critique: $0.0053 · 58,905 in / 1,356 out · 0 cached (0%) · deepseek/deepseek-v4-flash
security: $0.0057 · 58,285 in / 582 out · 8,964 cached (15%) · deepseek/deepseek-v4-flash, z-ai/glm-5.2
tests: $0.0012 · 14,629 in / 113 out · 0 cached (0%) · deepseek/deepseek-v4-flash
description: $0.0029 · 7,688 in / 1,391 out · 6,400 cached (83%) · z-ai/glm-5.2
tinysweeper
Bot
added
the
priority: p3
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
5 tasks
YellowSnnowmann
added a commit
that referenced
this pull request
Sep 4, 2026
#6007 fixed the routing for items synced from then on, and #6013 shipped it. Neither recovers the records already stored: the per-item sync gate treats an ingested document as done, so a re-sync fetches nothing and creates no tree rows. On the profile that reported the bug that is ~3000 documents, fully embedded in the document store and invisible to tree recall, the memory graph and the source row's ingest status. Recovery today means removing and re-adding the account, which re-fetches everything at the provider's expense. The walk itself lives in the engine (tinyhumansai/tinymemory#136), beside the funnel the sync path uses, so a backfilled row and a freshly-synced row are the same row. This is the host half: the module forwarder, the guard, and the RPC. - The forwarder takes the bulk deadline. A pass reads and re-embeds up to its whole limit of documents, and the default 30s bus deadline is what made the connector sync retry a finished handoff forever. - The guard takes the write tier, like every other mutating maintenance member. A readonly operator may inspect a store; re-filing thousands of its documents is not inspection. - `dry_run` defaults to TRUE at the RPC boundary. A pass costs one read and one set of chunk embeddings per document against the user's embedding budget (#5324), so a caller that omits the field gets the preview and the write is something they ask for. The response carries four counters rather than one because "did nothing" has three different causes an operator must tell apart: the tree already held everything, nothing could be addressed, or there was nothing to look at. Refs #6012
8 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Re-pins the memory module to v1.13.8, which is what actually turns on the #6007 fix for users.
tinyhumansai/tinymemory#134fixed the primary defect:MemorySourceSink::accept_source_itemswrote namespace documents and vector chunks but nevermem_tree_chunks, so a Gmail sync landed thousands of documents and embeddings while tree-backed recall, the Memory Tree graph and the source row's ingest status all reported zero. This repo only dev-depends ontinymemory-tinycortex; the production engine ships inside the prebuilt TinyBus module, so that fix reaches nobody until the pin moves.Four things move together, because they have to:
vendor/tinymemory→ thev1.13.8commit (ded26ae→c253e70)registry_part_01.rs→ version,release_url, and all 11 platform assets with their published checksumsARTIFACT_CAPABILITIES_PIN→1.13.8ci-full.yml,ci-lite.ymlande2e-reusable.ymlpinmemory_versionandmemory_sha256forubuntu-22.04-x86_64independently of the registry (4 sites;e2e-reusable.ymlhas two)That fourth one is easy to miss and
the_ci_workflows_pin_the_same_module_digest_as_the_registryexists to catch it — it caught this one. Without it the workflows would download the 1.13.8 archive, verify it against the 1.13.7 digest and refuse it, turning every E2E lane red for a reason that reads nothing like a stale pin.The Module Pin Gate asserts the registry pin matches the submodule pin, and
the_capability_list_matches_the_pinned_releasefails if the capability pin lags the registry — so splitting these into separate commits would just produce a red intermediate state.Verification
Checked rather than assumed, since a pin that points at the wrong build is silent:
git merge-base --is-ancestor f143a150 v1.13.8passes (f143a150is the feat(onboarding): calmer onboarding + local AI download snackbar #134 merge), andingest_connector_item_toleratedis present incrates/tinymemory-core/src/engine/sync.rsat the tag.sha256values were generated from the release's ownchecksum.tomlasset and then cross-checked back against it — 11/11 match, none published-but-unpinned. The archive name and its hash are rewritten as one unit, so a name cannot end up beside the previous release's hash.git diff v1.13.7..v1.13.8 -- crates/tinymemory-api/src/capabilities.rsreturns empty, soARTIFACT_CAPABILITIESitself is unchanged and only the pin string moves. The fix is behaviour insideSources/Maintenance, not a new family. Recorded in the comment next to the pin, matching the convention the surrounding notes already follow.vendor/shifts underneath this.What this does and does not fix
Does: newly-synced Composio items — every toolkit, not just Gmail (
gmail,github,notion,slack,linear,clickupall flow through the sameaccept_source_itemspath) — now producemem_tree_chunksrows keyed{toolkit}:{connection_id}:{item_id}, so the source row's ingest status, tree recall and the memory graph can all see them. Also fixes the companion leak:forget_sourcenow sweeps those per-item rows, so disconnecting an account no longer leaves its synced content retrievable in the tree.Does not: recover the records already on disk. The per-item sync gate treats already-ingested items as done, so a plain re-sync creates no tree rows for them; recovery today means removing and re-adding the source. Backfill is tracked in #6012.
Worth watching after this ships: connector ingest now embeds twice — once into
vector_chunks, once intomem_tree_chunks. On the profile in #6007 that is roughly 8000 additional chunk embeddings for one Gmail account, which touches the embedding budget #5324 added exhaustion warnings for.Relationship to the other #6007 PRs
With this merged, #6007 is fixed for new syncs and can be closed once #6011 lands.
Test plan
cargo fmt --all --checkcargo test --lib modules::— 96 passed, 0 failed, includingthe_capability_list_matches_the_pinned_releaseandthe_ci_workflows_pin_the_same_module_digest_as_the_registry(the latter failed on the first run and is what surfaced the workflow pins)checksum.toml(11/11)v1.13.8Refs #6007
Summary by CodeRabbit