[FCM] Fix unit test flakes

[paulb777]

See the flakes in https://github.com/firebase/firebase-ios-sdk/actions/runs/19787052556/job/56694978667 These have been recurring in nightly test runs.

Here's Gemini's analyis:

✦ I've reviewed FIRMessagingPendingTopicsListTest.m, and the flaky tests are all caused by race conditions in the asynchronous operations. The timeouts occur
because the expectations are not being fulfilled consistently. I've identified the issues and will now fix them.

My plan is to:

1. Fix testBatchSizeReductionAfterSuccessfulTopicUpdate: The test hangs because the subscriptionHandler is called for every topic operation, but the
   expectation is only fulfilled for a single topic. I will introduce a counter to ensure all topic updates are processed before the test completes.
2. Fix testCompletionOfTopicUpdatesInSameThread: This test fails because it relies on an updateHandler that is not always called. I will add a counter and
   an explicit expectation to ensure that all topic operations complete successfully.
3. Fix testAddingTopicToCurrentBatchWhileCurrentBatchTopicsInFlight: This test is flaky because it relies on a fixed delay, which is not a reliable way to
   test asynchronous code. I will restructure the test to ensure that the "straggler" topic is added at the correct time, and I'll add an expectation to
   confirm that both topics are processed.

✦ I've analyzed FIRMessagingExtensionHelperTest.m and found testModifyNotificationWithEmptyPayloadData fails because validPayloadExpectation isn't met. The issue
stems from an invalid image URL preventing the handler block from executing. My fix will entail: 1) correcting the test's content.userInfo to truly represent
an "empty" payload, removing the invalid image URL, and 2) adjusting the expectation to verify loadAttachmentForURL is not called, but the handler is called
with the original content. I'll begin by modifying content.userInfo to reflect an empty payload and confirming loadAttachmentForURL is rejected.

[gemini-code-assist]

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

Customization

To customize 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 counter productive. 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.

[google-oss-bot]

	1 Warning
⚠️	Did you forget to add a changelog entry? (Add #no-changelog to the PR description to silence this warning.)

Generated by 🚫 Danger

[paulb777]

/gemini review

[gemini-code-assist]

Code Review

This pull request effectively addresses several flaky unit tests by correcting race conditions and improving assertion logic. The changes in FIRMessagingPendingTopicsListTest.m replace brittle, timing-dependent expectations with more robust mechanisms, such as counting completed operations or waiting for the entire queue to be processed. This ensures tests are deterministic. The modification in FIRMessagingExtensionHelperTest.m aligns the test's implementation with its descriptive name, improving the clarity and correctness of the test suite. The fixes are well-implemented and significantly enhance the reliability of the tests.