fix: Initialize call in MultiProvider never completes when listening to non-completing flow

[PenguinDan]

This PR

We need to create a job to listen to events emitted by Child providers, otherwise, the coroutineScope block never terminates as it only returns once all child jobs have completed.

How to test

Added a unit test to cover this new case

[gemini-code-assist]

Summary of Changes

Hello @PenguinDan, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical issue in the MultiProvider where its initialize method would not complete if any of its child providers emitted events via a non-completing flow. The fix involves restructuring the event observation mechanism to run in a separate, managed coroutine scope, allowing the initialize function to finish its execution independently. This ensures the MultiProvider behaves predictably and doesn't block application startup or configuration.

Highlights

• Fix for MultiProvider.initialize completion: The initialize method in MultiProvider now correctly completes even when observing non-completing flows from child providers. Previously, the coroutineScope block would hang indefinitely.
• Managed Event Observation Job: Provider event observation is now launched within its own CoroutineScope with a SupervisorJob, managed by observeProviderEventsJob. This job is cancelled on subsequent initialize calls or during shutdown.
• Refactored OpenFeatureAPI cleanup: The providerEventObservationScope and its associated cancellation logic have been removed from OpenFeatureAPI as the responsibility for managing event observation is now handled within MultiProvider.
• New Unit Test: A new unit test, initializeFunctionCompletesWhenObservingNeverCompletingFlows, has been added to verify that the initialize function completes as expected when observing a Flow that does not complete.

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 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to fix an issue where the initialize call in MultiProvider could hang indefinitely when observing non-completing flows from child providers. The proposed solution involves creating a dedicated job for event observation. However, the implementation still places this long-running job within a coroutineScope that waits for its completion, so the original problem persists. My review includes a critical comment explaining the issue and suggesting a more robust pattern using a class-level CoroutineScope to manage the lifecycle of background tasks correctly. The changes also include some related code cleanup in OpenFeatureAPI and a new unit test, which are good additions.