Skip to content

fix(firestore,core,windows): per-engine BinaryMessenger, Firestore/Auth link order, Profile builds - #18516

Merged
Lyokone merged 1 commit into
mainfrom
fix/windows-firestore-messenger-and-linking
Aug 3, 2026
Merged

fix(firestore,core,windows): per-engine BinaryMessenger, Firestore/Auth link order, Profile builds#18516
Lyokone merged 1 commit into
mainfrom
fix/windows-firestore-messenger-and-linking

Conversation

@Lyokone

@Lyokone Lyokone commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Description

Fixes three Windows bugs.

1. cloud_firestore's BinaryMessenger was a class-level static, reassigned on every RegisterWithRegistrar. In an app hosting several Flutter engines (e.g. desktop_multi_window), the last engine to register owned the messenger process-wide: snapshot listeners opened from any other engine were delivered to the wrong isolate and silently never fired, and once that engine was destroyed the dangling pointer crashed the next snapshot call. It is now a per-instance member, passed to RegisterEventChannel / RegisterEventChannelWithUUID.

2. firebase_auth was linked before firebase_firestore. MSVC resolves static libraries in link-line order and the SDK declares no dependency between the two imported targets, so Firestore's create_credentials_provider_desktop.obj failed on unresolved external symbol "void * firebase::g_auth_initializer" unless the app also depended on firebase_auth (which put the lib back on the line, later). Reordered. Kept in cloud_firestore's own CMakeLists.txt rather than on the imported target in Core, following #18498.

3. Only DEBUG and RELEASE had an IMPORTED_LOCATION. The SDK never sets IMPORTED_CONFIGURATIONS, so every other configuration fell back to the Debug libraries. Flutter maps Profile's flags onto Release, so a Profile build compiled against the release CRT and linked debug-CRT libraries, failing on __imp__CrtDbgReport / __imp__invalid_parameter. PROFILE, RELWITHDEBINFO and MINSIZEREL now resolve to the release libraries — same class of bug as #18073, which fixed Release only. The windows job gained a --profile build so it cannot regress.

Related Issues

Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (melos run analyze) does not report any problems on my PR.
  • I read and followed the Flutter Style Guide.
  • I signed the CLA.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

  • Yes, this is a breaking change.
  • No, this is not a breaking change.

…th link order, Profile builds

Three separate Windows bugs:

- cloud_firestore stored its BinaryMessenger in a class-level static and
  reassigned it on every RegisterWithRegistrar, so in an app hosting several
  Flutter engines (e.g. desktop_multi_window) the last engine to register owned
  the messenger process-wide. Snapshot listeners opened from any other engine
  were delivered to the wrong isolate and silently never fired, and once that
  engine was destroyed the dangling pointer crashed the next snapshot call.
  The messenger is now a per-instance member threaded through the event channel
  builders.

- cloud_firestore listed firebase_auth before firebase_firestore. MSVC resolves
  static libraries in link-line order and the SDK declares no dependency
  between the two imported targets, so apps using Firestore without Firebase
  Auth failed with an unresolved firebase::g_auth_initializer.

- firebase_core patched IMPORTED_LOCATION only for DEBUG and RELEASE. The SDK
  never sets IMPORTED_CONFIGURATIONS, so every other configuration fell back to
  the Debug libraries. Flutter maps Profile's flags onto Release, so a Profile
  build compiled against the release CRT and linked debug-CRT libraries,
  failing on __imp__CrtDbgReport / __imp__invalid_parameter. Profile,
  RelWithDebInfo and MinSizeRel now resolve to the release libraries, and the
  windows e2e job gained a Profile build so it cannot regress.
@gemini-code-assist

Copy link
Copy Markdown
Contributor
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.

@Lyokone
Lyokone merged commit 5dfd289 into main Aug 3, 2026
42 of 48 checks passed
@Lyokone
Lyokone deleted the fix/windows-firestore-messenger-and-linking branch August 3, 2026 12:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants