Repository navigation
fix(browser): share corrupt-model reloads and keep writes made during eviction - #36
Merged
Merged
Conversation
… eviction Callers that shared a corrupt load now each retry once behind the same eviction instead of one marking the engine failed. A cache write that starts while an eviction waits is held until the delete finishes. The load limits are documented as idle limits. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…le it A caller that handled a shared corrupt load after the first eviction finished started a second one, which could delete the retry's fresh download. The eviction is now keyed to the failed load's rejection. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Comments Outside DiffThese findings could not be posted inline.
|
This branch was successfully deployed
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
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.
Devin left three late findings on #32 after it merged. This PR fixes the two real ones and clarifies the third.
Two callers that shared one corrupt model load got different answers. The first to catch the error queued the one reload, and the second saw the engine as already reloaded and marked it failed, which skipped the first caller's retry too. Each walk now tracks its own reload, so both callers retry the fresh download once, and a download that is corrupt again still stops there. The eviction is keyed to the failed load's rejection, which every sharing caller receives, so a caller that handles it late reuses the first eviction instead of deleting the retry's fresh download. A failed cache delete no longer aborts the retry.
The safe cache deletes an evicted key a second time once earlier writes settle. A new download that started writing during that wait could land first and then be deleted. A write that starts during an eviction now waits for the delete to finish.
The model load limits are idle limits: any download progress restarts them. The code comment and ARCHITECTURE.md now say so instead of describing a total deadline.
Root
bun run lint,typecheck,testandbuildpass. The tests for concurrent callers sharing a corrupt load and for a write during eviction fail on main and pass here. The late-caller ordering is covered by unit tests of the eviction helper; the end-to-end test cannot force that timing. No real browser or device was exercised.Created with Claude Opus 5.5 in Claude Code.
🤖 Generated with Claude Code