Files
ClaudeandVitor Pamplona f08e6976e1 fix(images): a joined image request runs its own fetch when the shared one fails
Review findings on SharedDownloadStrategy, each with a test that fails on
the previous version:

- A failure went to whichever request came back first. A signed BUD-01
  retry that joined an anonymous download of the same blob (same disk
  cache key) then inherited its 401 and the image failed for good. A
  failure is now the outcome of the request that started the download; a
  request that joined runs its own fetch, as with Coil's strategy.
- A cancellation thrown by the fetch itself reached a request that joined
  as if it were cancelled: Coil left the image on its placeholder. It now
  runs its own fetch. The `cut` flag, whose branch the lock made
  unreachable, is gone.
- An empty first response (Content-Length 0, before Coil's second request
  without cache headers) counted as small, so a large image could finish
  as an orphan. A size of 0 now says nothing.
- The orphan count could leak: the download's cleanup runs while its job
  is still active, so a decision taken right after it could mark the
  finished download an orphan that nothing would un-count, and after 6
  such leaks no orphan would ever finish. The cleanup now marks the
  download done under the lock, and decisions check that instead of the
  job's state.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B8z5DBLBCQu51Lw9zyqirx
2026-10-25 10:13:27 -04:00
..