Repository navigation
test(projects): rerun the large-document stall on the fixed release - #178
Merged
Merged
Conversation
after-fix.mjs seeds the same invented 95,200-byte document as run.mjs and runs exact registry Memo 0.79.0 / Core 0.367.0 / Base 0.47.1 under the same guard. The document is now found in one invocation, all five lanes are done and no checkpoint is returned. The result also records that each matching lane reads the whole document again: 476,300 charged bytes, five times the document. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
leemour
added a commit
to WireCatLabs/cli-core
that referenced
this pull request
Oct 20, 2026
#1676) ## Why The rerun of the large-document reproduction on Memo 0.79.0 ([cli-testing#178](WireCatLabs/cli-testing#178)) found the document, but charged 476,300 bytes for one 95,200-byte document. Each of its five matching lanes read the whole text again and only then dropped it as already found. ## What - When a page reports a record too large to share it, and another lane in this run (or an earlier invocation) already returned that reference, gathering records the lane on it and moves on. It does not read the record again. The page's cursor already points past it. - `take()` and this path share one `again(ref, lane)` helper, so a lane is recorded the same way. - Docs: `PROJECT-GATHERING.md` and the changelog. ## Testing - New test: a 95 KB document matched by two lanes charges less than twice its size. It fails on main (190,710 bytes) and passes here. - Services and context reader tests: 1,128 passed. Typecheck, lint, `docs:check`, `docs:lint` and the Bun smoke pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
leemour
added a commit
to WireCatLabs/cli-memo
that referenced
this pull request
Oct 20, 2026
Bumps `@wirecat/cli-core` 0.367.0 → 0.369.0 and releases 0.80.0. - 0.369.0 ([cli-core#1676](WireCatLabs/cli-core#1676)): `memo projects evidence` reads a large document once, not once per matching search (measured 476,300 charged bytes for one 95,200-byte document on 0.79.0, [cli-testing#178](WireCatLabs/cli-testing#178)). - 0.368.0 ([cli-core#1670](WireCatLabs/cli-core#1670)) comes along: left-chat reads. No Memo code change. Full suite 592 passed. Typecheck, lint, `lint:commands`, `contracts:check`, `docs:check`, `docs:lint`, `test:matrix:check`, `generate:check` and `release:check` pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
leemour
added a commit
that referenced
this pull request
Oct 20, 2026
## Why [#178](#178) showed the fixed release finding the large document, but charging 476,300 bytes for one 95,200-byte document: each of its five matching lanes read it again. [cli-core#1676](WireCatLabs/cli-core#1676) (Core 0.369.0, Memo 0.80.0) skips that read. Did it work on the released packages? ## Results Same script and invented document, exact registry Memo 0.80.0 / Core 0.369.0 / Base 0.47.1: | | Memo 0.79.0 | Memo 0.80.0 | | --- | --- | --- | | Charged bytes | 476,300 | 95,260 | | Reads | 10 | 6 | | Found / complete | 1 / true | 1 / true | ## What - `result-read-once.json` with the new run. - `after-fix.mjs` now pins Memo 0.80.0 / Core 0.369.0. The README says which commit produced the 0.79.0 result. - README table, index line and changelog. ## Testing Ran the commands in the README. lint, `docs:check`, `docs:lint`, `docs:spell` and `standards:check` pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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.
Why
#174 reproduced project gathering stalling on one 95,200-byte document (published Memo 0.76.0). Core 0.367.0 (cli-core#1668) and Memo 0.79.0 (cli-memo#345) fixed it. Does the released Memo now read the same document and finish?
What
performance/projects/large-document/after-fix.mjs: same seeding, guard and invented document asrun.mjs, on exact registry Memo 0.79.0 / Core 0.367.0 / Base 0.47.1. It asserts progress instead of the stall.result-after-fix.jsonand a new section in the README.run.mjsandresult.jsonare unchanged.Results
It also shows waste: every lane reads the whole document again before dropping it as already found, so the charge is five times the document. A Core follow-up will skip that second read.
Testing
Ran the commands in the README. typecheck, lint,
docs:check,docs:lint,docs:spellandstandards:checkpass.🤖 Generated with Claude Code