Field report: 40x rebuild wall-clock variance across OS users on one machine; check RSS ballooning (~12 GB); no repair path short of full rebuild

[seemantk]

Field report: large rebuild wall-clock variance across OS users on one machine; check RSS ballooning (~12 GB); no repair path short of full rebuild

Thanks first for mex — the scaffold + decision-log half has been rock solid for us across four concurrent agent clones. This report is entirely about the graph/check half, offered as field data (we noticed #115 already benchmarks graph-vs-grep, and #134 is working on freshness/safe recovery — this complements both).

Environment

• mex-agent 0.7.2, installed globally via homebrew node v26.7.0 on macOS 27.0 (arm64)
• Multi-agent monorepo, ~1.8k tracked files (Python backend + TS/Svelte frontend)
• Several agent clones on one physical machine, running under different OS users

Observations

1. ~40× rebuild wall-clock variance between users on identical hardware.

Two independent mex graph --json runs, same machine, same day, same mex version:

Run	Graph size	Wall clock
user A	~33k nodes (est.)	10.7 min
user B	53,673 nodes / 120,329 edges / 1,573 files	7.2 hours

Graph-size ratio is ~1.6×; time ratio is ~40×. Machine was otherwise idle-ish during both. We could not isolate the cause — suspects include per-user file watchers/indexers interfering, or something in $HOME env resolution — but we'd love to know what graph build is actually sensitive to, since hardware is controlled for here.

2. Post-rebuild check balloons to ~12 GB RSS.

First post-rebuild mex check reached ~11.9 GB RSS at 6m40s before being killed (by PID). The kill left a ~720 MB uncheckpointed WAL behind, i.e. exactly the degraded-store condition. A subsequent bounded run (timeout 120 …) ballooned again but exited cleanly (rc=124) and printed remediation guidance — the bounded-wrapper behavior works as designed.

3. No repair path short of full rebuild.

The 0.7.2 CLI has no checkpoint/vacuum/repair subcommand, so observation 2 creates a chicken-and-egg loop: verifying a healthy store requires a completing check; any killed check re-dirties the store; the only reset is another multi-hour rebuild (or 10-minute one, per observation 1, if you're lucky).

4. Staleness gating removes impact queries in practice.

A few days after a rebuild, mex impact <symbol> returns GRAPH_REBUILD_REQUIRED instead of answering with reduced confidence. In an active multi-agent repo this means impact queries are unavailable most of the time unless someone keeps re-running multi-minute/hour builds. (Presumably adjacent to #134's provenance-bound freshness work.)

What we'd love

• Any known causes/gotchas for the per-user rebuild variance in observation 1
• A supported recovery procedure for an uncheckpointed WAL that doesn't require full rebuild (even a "documented sqlite surgery" section would help)
• Thoughts on a memory ceiling or streaming mode for check

Happy to supply more data points (per-run timings, store sizes, sqlite3 schema dumps) if useful.

[theDakshJaitly]

Thank you for bringing this to our attention, we have started work on a fix.

Really sorry for any problems caused.

[Yashasvi2229]

Thanks for an unusually actionable report — we've traced all four observations to concrete mechanisms in 0.7.2, and reproduced the relevant behavior locally across six repos (90 → 39k source files, including the TypeScript compiler repo). What follows is confirmed from code + measurement, not speculation.

1. The ~40× rebuild variance is the TypeScript type-checker, and it's environment-sensitive by design.
The TS/JS extraction path creates a real ts.createProgram for every discovered tsconfig*.json (with each project's own compilerOptions — skipLibCheck is not forced), then runs getSemanticDiagnostics per file. That cost is dominated by the resolvable type surface: node_modules install state, @types, pnpm stores, and TS module resolution walking up parent directories out of the repo — all of which differ per OS user on one machine. Hardware was never the variable. Supporting data: we built a graph the same size as your user B's (55k nodes) in ~7 minutes on a repo with no node_modules installed; the one benchmarked repo with node_modules showed 2–3× worse per-file cost from just a ~100 MB install. Your fully-installed type-heavy monorepo is the far end of that curve.

2. The check RSS ballooning has a specific cause: mex check silently re-runs graph staging.
When any source mtime changed since the last build (in an active repo: always), check's grounding pass re-stages the entire corpus in-process — all TS programs and typecheckers held concurrently, plus tree-sitter WASM trees that are currently never freed. So your 12 GB check was effectively a full rebuild you didn't ask for. This is the bug we consider most severe, and the fix direction is clear: check's grounding pass will read the last published graph read-only and report graph staleness, never rebuild. Until that ships, the workaround is your bounded wrapper (which you found works as designed) — or running check before pulling large source changes.

3. Repair path — confirmed missing, and cheap to fix.
There is no checkpoint/repair subcommand in 0.7.2, and the read-only open path refuses a store with non-empty WAL, so your chicken-and-egg loop is real. A mex graph repair (writer-open + PRAGMA wal_checkpoint(TRUNCATE) + integrity_check) is planned. Documented surgery that works today, since the WAL itself is not corrupt — any clean writer-open checkpoints it:

sqlite3 .mex/graph.db "PRAGMA wal_checkpoint(TRUNCATE); PRAGMA integrity_check;"

If integrity_check returns ok, the store is healthy and no rebuild is needed.

4. The staleness gate is all-or-nothing, and too broad.
impact/query/get abstain on a manifest-hash mismatch, and that manifest hashes the content of every package.json and tsconfig*.json in the repo — so any dependency bump anywhere gates all reads until a full rebuild. In an active monorepo that's "unavailable most of the time," exactly as you observed. The planned fix (aligned with the freshness work in #134) is to answer with explicit stale provenance instead of abstaining.

On memory ceiling / streaming: agreed in principle; the near-term wins are making check read-only (above), releasing each TS program before the next project, and freeing parse trees — together these remove most of the ceiling problem before a streaming mode is needed.

Data that would help most (all quick, none require a rebuild):

1. Storage breakdown — which tables own your store's bytes (in our benchmarks, LSH fingerprint bookkeeping is 37–48% of every DB, which we plan to re-encode ~3–5× smaller with no behavior change):

   sqlite3 .mex/graph.db "SELECT name, SUM(pgsize)/1048576.0 AS mb FROM dbstat GROUP BY name ORDER BY mb DESC LIMIT 10;"
   

2. The variance discriminator — from user A's clone and user B's clone, at the same commit:

   du -sh node_modules 2>/dev/null; node --version; npx tsc --version
   time npx tsc --noEmit 2>/dev/null | tail -1
   

   Our hypothesis predicts the raw tsc type-check time diverges the same way your mex build times did, since mex runs the same checker under the hood. If it does, observation 1 is isolated completely — with no mex code involved; if it doesn't, that falsifies the hypothesis and points us at the other suspects (watchers/indexers) before we build the fix on a wrong premise. Also note which package manager each user's clone was installed with (npm/pnpm/yarn) — symlinked stores change TS resolution cost.
3. Program count — how many projects mex builds compilers for:

   find . -name "tsconfig*.json" -not -path "*/node_modules/*" | wc -l
   

4. Recovery validation — after the checkpoint surgery above: does integrity_check return ok, and does a subsequent bounded mex check get further than before? That tells us whether the documented-surgery section is sufficient or a real repair command needs more.

We'll track the fixes here; thanks again — this report moved several suspected issues into confirmed ones.

[seemantk]

Thanks for the detailed analysis — really impressive tracing across six repos.

We have the data you asked for, but with an important caveat: this repo is Python/Django with a Svelte/JS frontend — no TypeScript anywhere. There are zero tsconfig files, only a jsconfig.json for the frontend's svelte-check. So the TS type-checker variance hypothesis (observation 1) does not apply to our codebase — if rebuild variance exists here, the cause is elsewhere (tree-sitter Python/Svelte parsing, watchers, etc.).

That said, here's what we can contribute:

1. Storage breakdown (graph.db)

Table	MB
lsh_buckets	116.5
idx_lsh	86.3
unresolved_refs	47.9
node_fingerprints	23.7
edges	20.6
nodes	17.9
source_chunks	13.2
idx_unresolved_from_name	10.0
idx_unresolved_file_path	9.4
source_chunks_fts_data	9.0

Total .mex/ = 432 MB. LSH bookkeeping (buckets + idx) = 202 MB = ~47% of the store, consistent with your 37–48% benchmark.

2. Variance discriminator — not applicable

$ du -sh node_modules 2>/dev/null; node --version; npx tsc --version
v26.7.0
Version 7.0.2

$ time npx tsc --noEmit 2>/dev/null | tail -1
0.38s total  (runs instantly on empty project — no tsconfig, no TypeScript)

Python backend + vanilla JS frontend — no TypeScript compilation in either. The type-checker hypothesis can't explain variance here.

Note: the frontend does have node_modules (223 MB), but these are JS packages (Vite, Svelte, Playwright, etc.) — no TS compiler involved.

3. Program count

$ find . -name "tsconfig*.json" -not -path "*/node_modules/*" | wc -l
0

4. Graph stats

• 33,468 nodes
• 50,470 edges
• 5,983 source chunks

Summary

Issues 2, 3, and 4 (check silently rebuilding, missing repair path, overbroad staleness gate) are fully relevant to us regardless of language. Issue 1 needs a different explanation for non-TypeScript repos — we're happy to help test hypotheses there if useful.

We did not run recovery validation (data point no. 4) because we didn't want to modify the graph.db without coordinating — let us know if you'd like us to proceed.

[Yashasvi2229]

Thanks — this is exactly the data that was missing, and it changes the picture in two places.

Observation 1: no tsconfig does not mean no TypeScript compiler

The discriminator measured npx tsc, but mex never shells out to tsc — it uses the compiler API directly, and it does so even in a repo with zero tsconfig files. Source files not covered by any discovered project are collected into a single inferred program (src/graph/extraction/compiler.ts), configured with allowJs: true and moduleResolution: Bundler. Your frontend's .js / .jsx / .mjs / .cjs files land there, and Bundler resolution follows their imports into that 223 MB of node_modules to build the type graph — Vite, Svelte, and Playwright all ship .d.ts.

So the dependency-surface cost described in observation 1 does apply to your repo; it just arrives through the inferred program rather than a configured one. find -name "tsconfig*.json" | wc -l returning 0 is what routes all of your JS into that one program — it isn't what exempts you from the cost.

Two of the 0.7.3 changes target this directly: the per-file semantic type-check pass is now opt-in (that was the part whose cost scaled with the installed dependency surface), and every program — inferred included — is now created with skipLibCheck and noEmit. If you can re-measure rebuild variance on 0.7.3, that is the single most useful remaining data point on observation 1.

One more thing worth flagging for your stats: .svelte has no extractor in mex today. The indexed extensions are .ts .tsx .mts .cts .js .jsx .mjs .cjs .py .rs. Your 33,468 nodes are the Django backend plus plain JS — the Svelte component layer is not in the graph at all.

Storage: your breakdown is now stale, in a good way

0.7.3 re-encodes the fingerprint and LSH tables — binary MinHash sketches, integer band hashes, integer fingerprint references, and the composite primary key as the only index (idx_lsh is gone entirely). Those tables shrank ~86% across our benchmarks. Projected onto your numbers:

	v2 (yours)	v3 (projected)
lsh_buckets + idx_lsh	202.8 MB	~28 MB
node_fingerprints	23.7 MB	~4 MB
.mex/ total	432 MB	~235 MB

The migration is in place and lossless — no rebuild required, existing groundings keep resolving — and runs the next time a writing command executes (mex graph, mex sync, mex graph ground).

Your data surfaces something new

unresolved_refs (47.9 MB) plus idx_unresolved_from_name (10.0 MB) and idx_unresolved_file_path (9.4 MB) is 67.3 MB. After the v3 shrink, that becomes the largest consumer in your store — roughly 28% of it.

We had not seen this, because it doesn't dominate in the repositories we benchmarked: compiler-backed resolution resolves the large majority of references there, so the table stays small. In a Python codebase, duck typing means far more references never resolve and those rows persist. The table is deliberately retained — it is the source of truth that edges are rebuilt from on incremental sync — but retaining resolved rows at full width is probably not necessary, and neither is carrying two secondary indexes over a table that is only scanned during resolution.

Filing that as a separate follow-up, credited to this breakdown.

Recovery validation:

Yes please, and it's safe now. 0.7.3 is on npm now. 0.7.3 adds mex graph repair, which checkpoints a stranded write-ahead log and runs an integrity check in place — no rebuild, no destructive rewrite. Copy .mex/graph.db first if you want a rollback, but the command exists for exactly the situation you were reluctant to poke.

[seemantk]

Good news — 0.7.3 fixes the worst of it. Here's what we measured:

mex check ballooning — fixed ✅

mex check now runs in 3.3 seconds with no RSS ballooning. Previously it was silently rebuilding the entire graph (12 GB RSS). The read-only grounding pass is working as designed.

Graph rebuild timing — cross-clone variance

We have three clones of the same repo (beryl, beryl2, beryl3). We ran mex graph on two of them:

Clone	Build time	Graph size
beryl3	11m 34s	33,487 nodes, 50,529 edges, 1,538 files
beryl2	>30m (timed out at 30m, completed but timing lost)	688 MB graph.db

Same repo, same commit, same 0.7.3 — ~3× variance between clones. This is with zero tsconfig files, so all cost is coming through the inferred program path. We didn't measure beryl (no graph.db). We don't have a 0.7.2 baseline for comparison.

Recovery validation ✅

$ mex graph repair
Graph store healthy: checkpointed 223.1 MB of WAL; integrity ok. No rebuild needed.

$ sqlite3 .mex/graph.db "PRAGMA integrity_check;"
ok

The repair command worked exactly as documented. WAL was checkpointed, store is healthy.

Storage: LSH shrink confirmed, unresolved_refs now dominates

Table	v0.7.2 (MB)	v0.7.3 (MB)	Change
lsh_buckets	116.5	20.1	-83%
idx_lsh	86.3	gone	removed
node_fingerprints	23.7	10.8	-54%
unresolved_refs	47.9	47.9	unchanged
edges	20.6	20.6	unchanged
nodes	17.9	17.9	unchanged

As you predicted, unresolved_refs (47.9 MB) is now the largest single table — roughly 28% of the store after the LSH shrink. The two secondary indexes over it add another ~19 MB. Looking forward to the follow-up on that.

Observation 1 re: inferred program

Your explanation of the inferred program routing JS through Bundler resolution makes sense. With 0 tsconfig files, all frontend JS goes into one program and traverses the full node_modules dependency surface. The 0.7.3 changes (opt-in semantic type-check, skipLibCheck + noEmit on all programs) should reduce that cost.

The cross-clone variance above (~3×) suggests there may still be environment-specific factors at play even through the inferred program path. Worth noting that all three clones are on the same machine (macOS, same hardware), so this isn't a hardware difference — more likely filesystem state, npm cache, or symlink resolution differences between clones.

One new observation

.svelte files are not indexed. Our 33k nodes are Django Python + plain JS only — the Svelte component layer is invisible to the graph. Not necessarily a problem for our use case, but worth noting if Svelte support is planned.

Summary

Issue	Status
1. Rebuild variance	Partially addressed — inferred program cost reduced in 0.7.3, but we can't isolate variance without a TS-heavy repo
2. check RSS ballooning	Fixed ✅
3. Missing repair path	Fixed ✅
4. Overbroad staleness gate	Still relevant — any package.json change gates all reads
Storage bloat	LSH fixed ✅, unresolved_refs now the target

[Yashasvi2229]

Apologies for the slow reply, we were heads-down shipping 0.8.0, which brought the Wiki and the Project Hub, and this thread deserved more attention than it got in the middle of that. Thanks for your patience.

Update: observation 4 is now fixed, and with it every observation in this report except 1st.

Observation 4 -- fixed

mex check and the graph reads no longer refuse a store they can describe. The build manifest now separates engine identity (schema, compiler, extractor and resolver versions, grammar hash, corpus policy) from config file content, and a store can fall short of fresh in three bounded, separately-reported ways:

• config-drift — compiler inputs moved, so resolved references may be out of date
• parse-degraded — some files parsed partially, so the store is incomplete (every fact still true, just fewer)
• source-drift — some indexed files changed, so what the store says about those files is older

query / get / impact / scope now answer such a store and say so, instead of returning GRAPH_REBUILD_REQUIRED:

{"type":"status","graphStatus":"stale","reasons":["config-drift","source-drift"],
 "trusted":["definitions","containment","source"],"stale":["resolution","edges"],
 "recoveryCommand":"mex graph refresh"}

Drifted source is answered around rather than refused: drifted paths are excluded, the rest of the repository answers, and excluded nodes are reported as excluded rather than silently missing. Engine identity still fails closed — a store written by incompatible code refuses every read, unchanged.

Config identity is also no longer raw bytes. Reindenting a package.json or editing description used to invalidate every read; now only fields that actually affect extraction are hashed.

Verified end-to-end on a 3,253-file / 120-config monorepo — the closest shape we have to yours.

Two things fixed on the way that probably affect you

A single file could silently cost a repository its entire graph. Two separate causes, both now fixed:

1. A file above the corpus size limit was correctly skipped, but the publish gate then rejected the resulting candidate — so a long build produced no graph at all and reported status missing. That monorepo above went from unbuildable to 53,069 nodes / 86,232 edges.
2. A re-resolved path was compared as bytes rather than as a name, so casing differences between realpath output and the compiler host's lowercasing tripped a containment guard, one file at a time. This cost hono its entire index — it now builds to 381 files / 13,240 nodes.

Failed maintenance runs now render the diagnostics they already carried — which file, what was skipped, what blocked publication — instead of a single sentence.

Storage, following on from your breakdown: unresolved_refs no longer stores references the resolver already turned into edges. On our corpora that table plus its indexes shrank ~40%, whole store ~17%, with node and edge content hashes identical. Combined with the v3 fingerprint re-encode you measured (lsh_buckets −83%, idx_lsh removed), the two tables that dominated your 0.7.2 store are no longer the largest things in it.

Observation 1 -- still open, and your own data narrows it

We could not reproduce cross-clone variance here, but comparing your two reports suggests the runs may not be doing the same work:

	files	nodes	edges
user B (0.7.2)	1,573	53,673	120,329
beryl3 (0.7.3)	1,538	33,487	50,529

Same repository, file counts 2% apart — but 1.6× the nodes and 2.4× the edges. Edges come from reference resolution, and resolution cost scales with the resolvable type surface rather than with file count. If two clones resolve different amounts, the slower one is not mysteriously slower — it is genuinely doing more work, and the wall-clock ratio stops being surprising.

You mentioned one clone has a 223 MB node_modules. If the clones differ in install state, or were installed with different package managers, that alone changes how much the TypeScript compiler resolves for the same JavaScript sources — which is the mechanism behind the inferred program we described earlier.

The most useful data would be a comparison of graph output, not just timing, from two clones at the same commit:

# in each clone, same commit
mex graph --json                       # files / nodes / edges / parse health
mex graph status                       # now reports parse health and skipped files
du -sh node_modules 2>/dev/null
ls node_modules/.package-lock.json node_modules/.pnpm 2>/dev/null   # which package manager
which node && node --version && which mex

That last line matters more than it looks: different OS users can resolve a different node or a different mex install through their own PATH, and mex graph status now surfaces skipped files, which would reveal a clone quietly indexing less than another.

If the node/edge counts come back close and the times still diverge, the resolution hypothesis is wrong and we should look at watchers and filesystem state as you originally suspected. Either answer is progress.

Availability, and a request

All of the above is merged to main but not yet released — the latest published version is 0.8.0, which does not contain it. To try it now you would need to build from source; otherwise it lands in the next release.

When you do get to it, we would value a re-run of all four observations rather than just 4th — including a fresh storage breakdown, since unresolved_refs should no longer dominate. If anything you reported still reproduces, we would rather know than assume it is closed.

Thanks again — this report has driven three releases' worth of work, and two of the defects above were found only because we were chasing it.

[seemantk]

Cross-clone comparison (beryl / beryl2 / beryl3)

All three clones on the same machine, same mex and node versions:

Clone	Graph status	Parse health	frontend/node_modules	Root node_modules	mex	node
beryl	missing (never indexed)	0 ok	238M	empty	0.8.0	v26.8.1
beryl2	degraded (WAL active)	0 ok	196M	empty	0.8.0	v26.8.1
beryl3	stale (last: 2026-09-08)	1613 ok	223M	empty	0.8.0	v26.8.1

Branches differ (each clone is on its own feature branch off staging), so commits aren't identical.

Observation 1: Our clones have comparable frontend/node_modules sizes (196–238M) and the same mex/node versions. The hypothesis that different install states cause different resolution workloads may not explain the variance we see here — only beryl3 has ever built a successful graph. beryl and beryl2 have missing and degraded status respectively, so they haven't done the same work at all.

When the next release lands, we'll re-run all four observations as requested.

[seemantk]

Follow-up: 0.8.1 rebuild results

Upgraded to mex 0.8.1 and rebuilt the graph on beryl3:

Metric	0.8.0 (stale)	0.8.1 (fresh)
Build time	—	96s
Files	1613	1613
Nodes	33,487	34,897
Edges	50,529	52,378
Parse health	1613 ok	1613 ok
Status	stale	fresh
DB size	—	240M

Storage breakdown (0.8.1):

Table	Rows
lsh_buckets	1,065,024
unresolved_refs	120,793
edges	52,378
nodes	34,897
node_fingerprints	33,282
source_chunks	6,334

Observations:

• Build completed cleanly — the two silent-failure bugs (corpus size limit + path casing) did not trigger. Both fixes appear effective.
• lsh_buckets still dominates at 1M rows. The ~83% reduction you mentioned may not apply to our corpus shape, or the v3 re-encode didn't trigger on a fresh rebuild from a 0.8.0-era store.
• unresolved_refs at 120K rows — not yet dominating, but we'd want a fresh build from scratch (not a refresh) to see the full effect.
• Node/edge counts increased vs. the stale 0.8.0 snapshot, consistent with the store being rebuilt rather than patched.

[Yashasvi2229]

Thanks for both of these — the cross-clone table and the 0.8.1 rebuild are exactly the data this thread needed.

The number that matters most: beryl3 went from 11m34s to 96s

beryl3	build time	files	nodes	edges
0.7.3	11m 34s	1,538	33,487	50,529
0.8.1	96 s	1,613	34,897	52,378

A comparable graph, built roughly 7× faster. Two honest caveats: the branch has moved (75 more files), so it isn't a same-commit comparison; and 0.8.1 carries more than the fixes I described last time — it also includes #180, which cut the cost of writing a graph (fingerprint publication and SQL statement reuse; ~4.3× on the mex repository itself). So credit belongs to the release as a whole, not any single change.

This is also the best observation-1 data point so far, which brings me to your cross-clone table.

Cross-clone comparison — what it tells us

Agreed: with comparable node_modules sizes and identical mex/node versions across all three clones, install state looks much weaker as an explanation. And as you say, only beryl3 has a graph, so there is no like-for-like comparison yet.

One thing in that table is our fault, though: beryl2's 0 ok does not mean nothing parsed. When a write-ahead log file (graph.db-wal) is sitting next to the store, mex graph status doesn't open the database at all — it reports degraded, prints an empty parse-health placeholder, and suggests mex graph repair. That placeholder reads like "zero files parsed" when it actually means "not inspected"; we'll fix the wording. An interrupted build — for example one stopped by a 30-minute timeout — can leave exactly that file behind, and the store underneath may well be intact.

The test that would settle observation 1, now that 0.8.1 builds beryl3 in 96 s:

# beryl2 — recover first, then rebuild with a timer
mkdir -p ~/graph-backup && cp -p .mex/graph.db* ~/graph-backup/   # rollback copy, WAL included
mex graph repair
mex graph status
time mex graph rebuild --json

# beryl — first-ever build
time mex graph --json

For each clone: wall-clock time, files / nodes / edges, and final status. Same commit is ideal, but close file counts are fine.

• If both land near beryl3's ~100 s, the variance has most likely collapsed with 0.8.1 and we can close observation 1.
• If beryl2 is still several times slower with a comparable graph, the cause is specific to that clone, and we go back to your original suspects — watchers, indexers, filesystem state.

Storage: row counts aren't bytes

lsh_buckets. The row count is fixed by design: every fingerprint is split into 32 bands, one row each. Your 33,282 fingerprints × 32 = 1,065,024 — exactly your number. That was also true in 0.7.2 and 0.7.3: your 116.5 MB and 20.1 MB measurements were both taken on stores with roughly this many rows. What v3 changed was the size of each row (≈110 bytes → ≈19 bytes, going by your own numbers), not how many there are. 0.8.1's schema keeps that encoding and every build writes it, so there is no re-encode left to trigger. I'd expect this table to be around 20 MB of your 240 MB.

unresolved_refs. A fresh build from scratch wouldn't change anything here: any build or refresh that does work clears and rewrites every derived row, so your 120,793 rows already reflect the change. What that change did is narrower than "shrink the table" — it stopped storing references the resolver had already turned into edges. References that genuinely don't resolve are kept by design: they're what edges are re-resolved from, and what who-calls now falls back to for names with no indexed declaration.

In a Python codebase, duck typing leaves many references genuinely unresolved, and your ratio — 120,793 unresolved against 52,378 edges — suggests that on your repo the saving may be well below the ~40% we measured on TypeScript-heavy corpora. The same change also narrowed the table's indexes: it dropped one that duplicated a composite index, and restricted the status index to non-resolved rows. Three full indexes remain, and one of them now serves the who-calls fallback. If this table is still your largest consumer by size, that's a real finding and worth its own follow-up.

The comparison needs megabytes rather than rows — all read-only:

ls -la .mex/graph.db*     # is the 240M graph.db alone, or graph.db plus a WAL?
sqlite3 .mex/graph.db "SELECT name, SUM(pgsize)/1048576.0 AS mb FROM dbstat GROUP BY name ORDER BY mb DESC LIMIT 12;"
sqlite3 .mex/graph.db "SELECT status, COUNT(*) FROM unresolved_refs GROUP BY status;"
sqlite3 .mex/graph.db "SELECT language, COUNT(*) FROM unresolved_refs GROUP BY language;"

The second query should show no resolved rows at all; the third will show how much of the table is Python.

On the two silent-failure fixes

It's good they didn't trigger, but I wouldn't count it as evidence either way: beryl3 already built cleanly on 0.7.3, before either fix existed, so beryl3's branch was never hitting those bugs. They mattered for other shapes of repository — one with a very large generated source file, and one whose path casing tripped a containment check. The casing fix applies on macOS too, though, and beryl and beryl2 are on different branches — so if beryl has ever attempted a build and failed with Could not stage … source file(s), that's worth mentioning.

Before you re-check observation 4: large-store reads are slow

Observation 4 is fixed in the sense you reported it — query / get / impact now answer a drifted store and label it instead of refusing. But on a store your size they're slow: each targeted read currently runs a store-wide integrity check twice before answering. On a 288 MB store we measured ~143 s for a single lookup, against ~6.9 s for graph scope over the same store. That is tracked separately in #190 and is not fixed in 0.8.1. On your 240 MB store, expect those reads to take minutes; mex graph scope stays fast. If that's what you see, it's #190 rather than a regression of observation 4.

Where things stand

	status
1. Rebuild variance	beryl3 ~7× faster on 0.8.1; open until beryl and beryl2 are built on 0.8.1
2. check RSS ballooning	fixed (your confirmation, 0.7.3)
3. Repair path	fixed (your confirmation, 0.7.3)
4. Staleness gate	fixed in 0.8.1; read latency on large stores tracked in #190
Storage	LSH shrink confirmed; unresolved_refs pending a by-size breakdown

Thanks again — every round of data you've sent has either confirmed a fix or found the next thing to fix.