fix(storage, apple): release finished tasks instead of keeping them for the life of the process - #18747
fix(storage, apple): release finished tasks instead of keeping them for the life of the process#18747gleb-r wants to merge 1 commit into
Conversation
…orever The Swift plugin (13.0.4+) registers every upload/download task in eventChannels/handleToTask/handleToPath/handleToIdentifier and never removes an entry, while StorageUploadTask keeps uploadData and its fetcher alive for the life of the task object, so every putData payload stayed in memory. A camera app uploading ~50 clips per hour grew ~80 MB per hour until jetsam. Release a task when the Dart side cancels its event stream (which happens right after the terminal event), sweep tasks that finished without any listener after a 30 s grace period, and release everything on engine detach. The event channel's stream handler is cleared one run-loop turn after the Dart cancel so that cancel still lands on a live handler. pause/resume/cancel on a released task answer status:false, as Android does for an unknown task. Mirrors the ObjC cleanUpTask:handle: (<= 13.0.3) and Android's FlutterFirebaseStorageTask.destroy(). Visory VIS-2594. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. |
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Description
The Apple (iOS/macOS)
firebase_storageplugin never releases a finished task.registerTaskstores every upload/download task inhandleToTask,handleToPath,handleToIdentifierandeventChannels, and nothing ever removes an entry (thestreamHandlersmap is declared but never written). The Firebase iOS SDK'sStorageUploadTaskkeepsuploadDataand itsGTMSessionUploadFetcheralive for the life of the task object, so the payload of everyputData/putStringstays in memory for the life of the process. The ObjC implementation (≤ 13.0.3) released tasks per task incleanUpTask:handle:, and the Android plugin still does so inFlutterFirebaseStorageTask.destroy().Observed in production: an app that uploads ~50 short video clips per hour (plus a preview image and two small sidecars per clip) grows by ~80 MB per hour on iOS until the jetsam watchdog terminates it. Over several measured windows the process footprint grew by exactly the uploaded bytes plus ~40–90 KB per task, while the same Dart code on Android stayed flat.
This PR releases tasks the way the ObjC plugin and Android do:
MethodChannelTaskdoes right after the terminal success/error event), the stream handler reports back to the plugin, which drops the task from every registry, removes the event channel and clears its stream handler one run-loop turn later, so the Dartcancelcall still lands on a live handler (noMissingPluginException"while de-activating platform stream" report).registerTaskonce they have been finished for 30 s (a plugin-level finish watch stamps the time). A listener that attaches within that window still gets the terminal event replayed by the SDK.detachFromEngine(for:)releases everything (the iOS plugin instance is now published so the engine calls it).pause/resume/cancelon a released task keep answeringstatus: false, exactly like Android for an unknown handle.The macOS sources are symlinks to the iOS files, so both platforms get the change. This is complementary to #18658, which clears the registries on engine detach and Firebase Core re-initialization but does not release individual tasks while the app keeps running.
Testing: 2 h on-device run (iPhone 15 Pro, iOS 26, profile build) with the patched plugin: 123 clip uploads (293 MB video) + 123 preview uploads (37 MB) + sidecars ≈ 490 tasks — process footprint 270 → 298 MB (max 314 MB), where the unpatched plugin grew by ≈ +350 MB for the same uploads in the previous session; an iPhone 11 Pro (iOS 17.4) uploading only previews stayed flat (258 → 270 MB). Device logs showed no
MissingPluginException/ de-activating-stream reports and no storage errors; all uploads completed and their DartonComplete/ snapshot streams behaved as before. No Dart code changes, so the existing Dart test suites are unaffected.Related Issues
No existing issue found for the per-task accumulation; related to #18658 (Apple task listener cleanup on detach / re-initialization).
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]).This will ensure a smooth and quick review process. Updating the
pubspec.yamland changelogs is not required.///).melos run analyze) does not report any problems on my PR. (No Dart changes.)Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?
🤖 Generated with Claude Code