Keep a capture's shared download client open until the capture ends - #232
Merged
Merged
Conversation
A capture's downloads shared one client through http.runWithClient so a failed capture could abort the rest. But package:http's top-level get closes whatever client it picked up when its request finishes, so the first finished download closed the shared client: in a browser that aborts the other downloads in flight and refuses a refresh after an expired URL, and a screenshot of a page with two or more cloud images failed with "Couldn't load the images on this page." The fetcher now receives the capture's client and downloadCloudImageBytes calls client.get on it, so only the capture closes it, once it is done. A test serves three images (one refreshed after an expired URL) through a client that, like BrowserClient, refuses requests once closed; it fails with the old behaviour. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
SunkenInTime
added a commit
that referenced
this pull request
Sep 29, 2026
The fetcher now receives the capture's client (#232); passing it to downloadCloudImageBytes keeps one finished download from closing it for the rest. 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
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.
Hotfix for #229, which is live on the beta. Greptile caught it while reviewing #230.
Bug: a web screenshot of a page with two or more cloud images, or with one whose signed URL has expired, fails with "Couldn't load the images on this page."
Cause: my last change to #229 aborts a failed capture's other downloads. To do that, it gave the capture's downloads one shared client through
http.runWithClient. But package:http's top-levelhttp.getcloses whatever client it picks up once its request finishes (_withClient→client.close()). So the first download to finish closes the shared client:BrowserClient.close()aborts the other downloads in flight.Nothing is saved wrong, but screenshots of those pages don't work. Desktop is mostly unaffected, since cloud images there usually come from cached files.
Fix: the capture passes its client to the fetcher explicitly, and
downloadCloudImageBytestakes an optionalclientand callsclient.get. Now only the capture closes the client, when it's done, which still aborts leftover downloads after a failure. The fetcher type's doc says to useclient.get, never the top-levelget.Verification
test/capture_images_test.dart, "downloads and URL refreshes share a client nothing closes early": a client that, likeBrowserClient, refuses requests afterclose()serves three images (fast, slow, and one whose URL is expired and gets refreshed). All three resolve.flutter testpasses (1333, 5 skipped), and the analyzer is clean.BrowserClient), three cloud images resolve through one capture client, including one refreshed after a 404. The screenshot and both video presets still pass.runWithClientremains anywhere inlib/.🤖 Generated with Claude Code
No blocking issues found; safe to merge.
What we checked:
Summary
The PR passes the capture-owned HTTP client to cloud image downloads so one completed request cannot close the client needed by another download or a signed-URL refresh. Focused checks completed concurrent downloads and a refresh, confirmed cleanup after a failed download, and passed all 17 capture-image and page-screenshot tests.
Reviews (1) · Last reviewed commit: "Keep a capture's shared download client ..."