[firebase_storage] Windows native crash in upload progress callback, sink ownership and thread dispatch #18664

Concurrent putData calls can terminate the Windows process with an unhandled access violation in TaskStateListener::OnProgress / flutter::EventSink::Success. A Dart catch cannot catch this native exit.

Reproduced with firebase_storage 12.4.10, Firebase C++ SDK 12.7.0, and a Windows release build on Windows Server 2019 (17763). The relevant ownership and callback code is also present in current main (a57837e, firebase_storage 13.5.0); I have inspected that source but have not runtime-tested 13.5.0.

After normal Firebase initialization and authentication, run repeated bursts of small uploads to an authorized test path:

final bytes = Uint8List.fromList(utf8.encode(jsonEncode({
  'id': List.generate(300, (i) => i),
  'label': List.generate(300, (i) => 'Synthetic customer $i'),
})));
for (var round = 0; round < 3; round++) {
  await Future.wait(List.generate(13, (i) => FirebaseStorage.instance
      .ref('YOUR_TEST_PATH/${DateTime.now().microsecondsSinceEpoch}_$i.json')
      .putData(bytes, SettableMetadata(contentType: 'application/json'))));
}

The storage-only reproduction initializes Core/Auth/Storage, with no Hive, Firestore database initialization, or SQL. The unchanged plugin exited with 0xC0000005 about 14 seconds into one run. A separate release-app dump identifies the progress callback stack:

flutter::EventSink<flutter::EncodableValue>::Success
TaskStateListener::OnProgress
firebase::storage::internal::RestOperation::NotifyListenerOfProgress

Three relevant findings in the Windows plugin:

• PutDataStreamHandler, PutFileStreamHandler, and GetFileStreamHandler store the sink as a std::unique_ptr<...>&& member. OnListenInternal assigns into that referenced temporary instead of owning the incoming sink.
• Progress and completion call EventSink::Success from SDK worker threads. Flutter's platform message API requires the platform thread.
• Keeping only the sink alive was insufficient in our stress checks: transfers could upload remotely while Dart completions remained pending. Keeping the exact StorageReference that starts each operation alive through completion, and moving completion processing onto the platform thread, resolved the tested stalls. SDK 12.7 source shows a potential FutureManager/API mutex inversion when a reference is orphaned during a pending Metadata result; I am not claiming the dump alone proves that entire lock cycle.

A local plugin candidate owns the sinks, posts events through a message-only Windows window, retains operation references and buffers until completion, and drops callbacks after plugin shutdown. It has passed 140 small uploads with byte-for-byte SDK readback (including ten bursts of 13), metadata updates, putString, putFile/writeToFile, overwrite, download URL, a 13 MB result, accepted pause/resume, eight accepted cancellations, missing-object and signed-out errors, and uploads after signing back in. The unchanged native plugin still crashes with the same Dart harness. Requested close during 13 active uploads exits without leaving a process. A separate super_native_extensions/msctf error during requested process shutdown also occurs without any Storage upload in the unchanged plugin, and in our previous full-app build; that is outside this report.

Candidate patch: BlazeSQL@f9ea660 (based on our existing Firestore fork; this commit changes only Windows Storage).

Could you confirm the intended sink/reference lifetime and platform-thread dispatch approach? I can supply a minimal patch or further diagnostics. No customer data is needed to reproduce this.