feat: Propagate fatal error on wait for init

[chrfwow]

This PR

Propagates fatal stream error to thread waiting for initialization

Related Issues

Fixes #1675

[gemini-code-assist]

Summary of Changes

Hello @chrfwow, 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 refines the error handling within the FlagdProvider to ensure that fatal stream errors are not merely acknowledged but are fully propagated with their specific details to any threads that are actively waiting for the provider to initialize. This change prevents scenarios where a provider might enter a fatal state without the waiting threads being informed of the underlying cause, leading to more robust and transparent error management.

Highlights

• Enhanced Fatal Error Propagation: The FlagdProvider now correctly captures and propagates detailed ProviderEventDetails when a fatal error occurs, ensuring that the specific error message and code are preserved.
• Improved Initialization Waiting Logic: The waitForInitialization mechanism in FlagdProviderSyncResources has been updated to immediately cease waiting and throw a FatalError if a fatal condition is detected, preventing indefinite waits.
• Dedicated Fatal Error State Management: A new fatalError method and fatalProviderEventDetails field were introduced in FlagdProviderSyncResources to centralize and manage the state and details of fatal errors.
• Comprehensive Test Coverage: New unit tests have been added to validate the precedence of fatal errors over initialization and shutdown, and to confirm that fatal errors correctly abort ongoing initialization processes.

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 correctly propagates fatal stream errors to threads waiting for initialization. The changes introduce a mechanism to store fatal error details and use them to interrupt the initialization wait, throwing a FatalError. The logic is sound and well-tested. I have one critical suggestion to ensure the ErrorCode is correctly propagated within the thrown FatalError, which is necessary for the new tests to pass and aligns with the overall goal of this change.

[gemini-code-assist]

The FatalError exception is being thrown without propagating the ErrorCode from fatalProviderEventDetails. The test initAfterFatalPropagatesErrorEvent asserts that the ErrorCode should be PROVIDER_FATAL, but the current FatalError constructor only takes a message. This likely defaults to the GENERAL error code in the underlying OpenFeatureError, which would cause the test to fail.

To ensure the correct error code is propagated, you should use a constructor that accepts an ErrorCode. Assuming FatalError has been updated in the SDK to include a constructor that takes an ErrorCode, you should use it to pass the error code from the event. This will ensure the error code is correctly propagated as intended.

Suggested change

	if (isFatal) {
	var fatalEvent = fatalProviderEventDetails;
	if (fatalEvent != null) {
	throw new FatalError("Initialization failed due to a fatal error: " + fatalEvent.getMessage());
	} else {
	throw new FatalError("Initialization failed due to a fatal error.");
	}
	}
	if (isFatal) {
	var fatalEvent = fatalProviderEventDetails;
	if (fatalEvent != null && fatalEvent.getErrorCode() != null) {
	throw new GeneralError(fatalEvent.getErrorCode(), "Initialization failed due to a fatal error: " + fatalEvent.getMessage());
	} else {
	throw new FatalError("Initialization failed due to a fatal error.");
	}
	}

[chrfwow]

I assume that the user only invokes fatalError(...) only with a fatal error. I do not plan to add any checks to that matter, because there is nothing to do in this case.
Therefore I will ignore this comment