fix(browser): evict a damaged model even after its callers cancel

[leoisadev1]

Follow-up to #39. A load that joins another load's read of the model file cannot evict it, so the load that read the file has to. That eviction ran in the engine walk, which stops as soon as its caller cancels. If the caller that owned a corrupt read cancelled, nobody evicted the damaged file, and a joined load on another provider could retry against the same bytes and fail again.

The shared load now evicts a damaged copy from its own failure handler, which runs whether or not anyone is still waiting. The walk still awaits the eviction before its retry; it shares the one the load started, since the tracker evicts each copy once. A load without a recorded copy still never evicts.

Two tests are new. One cancels the only caller of a corrupt load, lets the load fail, and checks the file is evicted. The other evicts the file after a load starts but before it opens the file, has the load read a damaged replacement, and checks the retry does not see it. That pins the recorded copy to the file-open event rather than load creation. Each test fails against its own regression and passes otherwise. Root lint, typecheck, test (191 browser, 98 web) and build pass.

On the build of 1af41cf, the tree now on main at 813bf5d, I ran the remover in headless Chrome against a fresh origin: model download, WASM processing, an RGBA PNG with real transparency, download, reset and an unreadable-file error. I then overwrote the cached model with zeros of the same size and processed again. The damaged copy was evicted, downloaded fresh, and the photo processed. WebGPU and iPhone were not tested.

Created with Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
bg0-web	Ready	Preview	Sep 29, 2026 5:35pm UTC

1 Skipped Deployment

Project	Deployment	Actions	Updated
bg0-docs	Skipped		Sep 29, 2026 5:35pm UTC

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Fixes model cache eviction when loads fail after callers cancel.

Do not merge until an old load can no longer delete a healthy model cached after reset. The test-timing issue is non-blocking.

Findings

1.  Reset evicts healthy model ▶
2.  Wait for file open ▶

Summary

The PR moves damaged-model eviction into the shared load’s failure handler so cleanup can continue after every caller cancels. A cache reset during an outstanding load can cause that handler to delete a healthy replacement. The new cancellation test can also fail when the model file opens later than its fixed wait.

_{Reviews (1) · Last reviewed commit: "fix(browser): evict a damaged model even..."}

[greptile-apps]

Comments Outside Diff

These findings could not be posted inline.

•  Cancelled pre-reset load evicts a healthy post-reset cache entry ▶

  • Bug
    • After the old load reads damaged copy 0 and its caller cancels, clearModelCache() resets the copy tracker. A fresh load caches a healthy file as copy 0. When the old load later fails, its failure deletes that healthy file.
  • Cause
    • clearModelCache() replaces modelCache at packages/browser/src/index.ts:179, but the old load retains its numeric copy 0. The failure handler at index.ts:676–677 passes that number to corruptModels.fail; the current cache also reports copy 0, so eviction.ts:25–33 treats the two unrelated cache generations as the same copy.
  • Fix
    • Associate each recorded copy with its cache generation and reject eviction when the failing load's generation differs from the current cache's generation.

•  Fixed wait does not establish that the load opened the cached model ▶

  • Bug
    • The test can assert eviction after cancellation while its mocked load has not yet opened the file. A deterministic delayed-open run fails the original cache assertion; once opening and the corrupt failure proceed, eviction occurs.
  • Cause
    • The 10 ms timer at line 730 is used as a proxy for the mocked from_pretrained reaching openModelFile, without synchronizing on that event.
  • Fix
    • Have the mock signal immediately after openModelFile, and await that signal before aborting. Retain a separate gate for releasing the corrupt failure.