flutterfire icon indicating copy to clipboard operation
flutterfire copied to clipboard

[firebase_core]: <runTransaction throws an exception on Windows.>

Open gustavosanabio27 opened this issue 1 year ago • 9 comments
trafficstars

Is there an existing issue for this?

  • [X] I have searched the existing issues.

Which plugins are affected?

Core, Database

Which platforms are affected?

Windows

Description

Using "runTransaction()" generates an error in Windows and closes the application immediately. The same code normally works for Flutter Web.

Reproducing the issue

DocumentReference dbVersionsRef = db.collection("any/collection").doc(docID); await db.runTransaction((transaction) async { // do something });

Firebase Core version

3.3.0

Flutter Version

3.24.0

Relevant Log Output

No response

Flutter dependencies

Expand Flutter dependencies snippet

Replace this line with the contents of your `flutter pub deps -- --style=compact`.

Additional context and comments

No response

gustavosanabio27 avatar Aug 12 '24 21:08 gustavosanabio27

I got a same issue! Windows apps automatic close

AkidFikriAzhar avatar Sep 15 '24 15:09 AkidFikriAzhar

I encountered the same issue with Firebase transactions in Flutter. The app crashes without any error message when performing a transaction after any .get() operation has occurred in the program. Here's what I found:

  1. Issue Description:

    • The app crashes silently when executing a Firebase transaction if any .get() operation has been performed earlier in the program's execution.
    • It doesn't matter where in the program the .get() operation occurs; as long as it happens before any transaction, subsequent transactions will crash.
    • The crash occurs without any error message, making it difficult to debug.
    • Commenting out all lines with .get() prevents the crash.
  2. Workaround: I discovered that adding an empty transaction at the start of the program, before any .get() operations, prevents the crash. Here's the workaround I'm currently using:

    void main() async {
      // Execute an empty transaction at the start of the program
      await FirebaseFirestore.instance.runTransaction((transaction) async {});
    
      // Now .get() operations can be performed anywhere in the program without causing subsequent transaction crashes
      // For example:
      CollectionReference collection = FirebaseFirestore.instance.collection('testCollection');
      DocumentSnapshot document = await collection.doc('document_id').get();
    
      // ... other code ...
    
      // Later in the program, transactions will work fine
      final FirebaseFirestore db = FirebaseFirestore.instance;
      final sfDocRef = db.collection("testCollection").doc("testDoc");
      db.runTransaction((transaction) async {
        final snapshot = await transaction.get(sfDocRef);
        final newPopulation = snapshot.get("counter") + 1;
        transaction.update(sfDocRef, {"counter": newPopulation});
      }).then(
        (value) => print("DocumentSnapshot successfully updated!"),
        onError: (e) => print("Error updating document $e"),
      );
    
      runApp(MyApp());
    }
    
  3. Additional Observations:

    • The issue seems to be related to how the Firebase SDK handles the global state after any .get() operation.
  4. Environment Details:

    • Flutter version: 3.24.3
    • Firebase Core version: ^3.5.0
    • Cloud Firestore version: ^5.4.4
    • Platform: Windows

While the empty transaction workaround allows me to proceed with development, it's clearly not an ideal solution. It's particularly concerning that this issue affects the basic flow of Firestore operations and requires a global workaround.

I hope this information helps in identifying and resolving the root cause of the problem. Please let me know if you need any additional information or if there are any specific tests I can run to help diagnose this issue further.

Nevenit avatar Oct 08 '24 23:10 Nevenit

Our company is stuck on version 5.0.1 of cloud_firestore. After this version, runTransaction stopped working on the Windows platform. It is an essential feature for data integrity. I don’t understand why they are releasing new versions with additional features when basic features that used to work are no longer functioning.

gustavosanabio27 avatar Oct 30 '24 12:10 gustavosanabio27

Hi @Nevenit Your solution works fine for me in debug mode, but it doesn’t work in release mode. Were you able to get it working in release mode?

gustavosanabio27 avatar Feb 06 '25 14:02 gustavosanabio27

We experienced the same issue. Are there any updates yet?

ConschiB avatar Mar 15 '25 13:03 ConschiB

Same here - any news.

markbreuss avatar Mar 17 '25 12:03 markbreuss

The solution from @Nevenit works well. You just need to run an empty transaction at the beginning of the program. More specifically, before any first get().

However, in the release version, we had issues with this solution when used together with the media_kit 1.1.11 package. Before distributing the release version to clients, it is necessary to update the following 5 files in the "Release" folder.

These are: msvcp140.dll, msvcp140_1.dll, msvcp140_2.dll, vcruntime140.dll, and vcruntime140_1.dll.

The good files are located in the folder: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC

gustavosanabio27 avatar Mar 18 '25 19:03 gustavosanabio27

@gustavosanabio27 yes, the solution works generally. But in our application, we need to launch another window (window_manager_plus package) and after that, the workaround doesn't work any more. So I am really looking forward to see any progress in the firebase package itself.

ConschiB avatar Mar 20 '25 06:03 ConschiB

It doesn’t seem like this issue is going to be addressed anytime soon, and I’m not sure if any maintainers have reviewed it. If you’re looking for alternatives, you might consider migrating to a different backend. Supabase, for example, offers a migration path from Firebase, and PocketBase is another option worth exploring. It’s more of a workaround than a true solution, but given the circumstances, it might be the best path forward.

Nevenit avatar Mar 20 '25 23:03 Nevenit