[WIP] feat: Created methods to validate and register providers input

[Tmakinde]

Task

Multiprovider feature: https://openfeature.dev/specification/appendix-a#multi-provider

[gemini-code-assist]

Summary of Changes

Hello @Tmakinde, 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 establishes the foundational Multiprovider class, which is crucial for handling multiple feature flag providers. It focuses on robust input validation and systematic registration of providers, ensuring data integrity and preventing naming conflicts, thereby setting the stage for advanced multiprovider capabilities.

Highlights

• New Multiprovider Class: Introduced a new Multiprovider class to manage multiple feature flag providers, aligning with the OpenFeature multiprovider specification.
• Provider Data Validation: Implemented validateProviderData to ensure provider input arrays contain only supported keys, have non-empty names, and prevent duplicate explicit provider names.
• Provider Registration and Unique Naming: Developed registerProviders and uniqueProviderName methods to register providers by name, automatically generating unique names for providers that are unnamed or have conflicting names by appending a numerical suffix.

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 introduces a Multiprovider class to handle multiple feature flag providers, which is a great step towards implementing the multi-provider feature from the OpenFeature specification. The implementation correctly handles validation of provider data structure and generation of unique names for unnamed providers. However, I've found a high-severity issue in the provider registration logic that could lead to providers being silently overwritten if there's a name collision between an explicitly named provider and a previously registered provider with a generated name. My review includes a suggested fix to prevent this and ensure all provider names are unique as required by the specification.

[gemini-code-assist]

The current implementation of registerProviders has a bug where an explicitly named provider can silently overwrite a previously registered provider if their names conflict. This happens because there's no uniqueness check for providers that have an explicit name. This violates the requirement that all provider names must be unique.

For example, if the provider data is [['provider' => $provider1], ['name' => 'TestProvider', 'provider' => $provider2]] and $provider1->getMetadata()->getName() returns 'TestProvider', the first provider will be registered with the generated name 'TestProvider', and then the second provider will overwrite it.

I suggest refactoring this method to determine the name first (either explicit or generated) and then perform a single check for uniqueness before registering the provider. This makes the logic cleaner and ensures no provider is ever overwritten.

 $counts = []; // track how many times a base name is used foreach ($providerData as $entry) { if (isset($entry['name']) && $entry['name'] !== '') { $name = $entry['name']; } else { $name = $this->uniqueProviderName($entry['provider']->getMetadata()->getName(), $counts); } if (isset($this->providersByName[$name])) { throw new InvalidArgumentException('Duplicate provider name detected during assignment: ' . $name); } $this->providersByName[$name] = $entry['provider']; }

[tcarrio]

Hey @Tmakinde , initial thoughts here is that other languages utilized the contrib repository for implementing the multi provider. The reasoning as I understand it is it's an extension of the primary provider, not a function of it itself.

That said it would be fairly straightforward to add support for it there

@beeme1mr is that the expectation for all languages?

[Tmakinde]

Hey @Tmakinde , initial thoughts here is that other languages utilized the contrib repository for implementing the multi provider. The reasoning as I understand it is it's an extension of the primary provider, not a function of it itself.

That said it would be fairly straightforward to add support for it there

@beeme1mr is that the expectation for all languages?

Ooh.

Please let me know the best place to implement this.
@beeme1mr told me it should be in php-sdk repo.

Please confirm.

[beeme1mr]

We've been slowly moving the multi-providers to the SDKs themselves. The logic being that it's easier to access and manage provider state from within the SDK and it shouldn't add too much complexity to the SDKs. The .NET SDK is a good example of what we're looking for.

[Tmakinde]

We've been slowly moving the multi-providers to the SDKs themselves. The logic being that it's easier to access and manage provider state from within the SDK and it shouldn't add too much complexity to the SDKs. The .NET SDK is a good example of what we're looking for.

Thank you @beeme1mr