feat: Add multi-provider support #1500

suvaidkhan · 2025-07-01T07:43:28Z

This PR

Added Multiprovider class
Added Strategies
Added a new dependency for JSON

Related Issues

Resolves #1486

Follow-up Tasks

Multiprovider should be removed from the contrib codebase

chrfwow

Looks good so far!
I'm not sure if we want to add a json dependecy (which might also produce the License Compliance error) "just" so that we can build up the metadata name string.

chrfwow · 2025-07-01T08:28:09Z

src/main/java/dev/openfeature/sdk/multiprovider/MultiProvider.java

+    private String metadataName;
+
+    /**
+     * Constructs a MultiProvider with the given list of FeatureProviders, using a default strategy.


I think the comment should say what the default strategy is

chrfwow · 2025-07-01T08:33:01Z

src/main/java/dev/openfeature/sdk/multiprovider/MultiProvider.java

+        json.put("name", NAME);
+        JSONObject providersMetadata = new JSONObject();
+        json.put("originalMetadata", providersMetadata);
+        ExecutorService initPool = Executors.newFixedThreadPool(INIT_THREADS_COUNT);


Suggested change

ExecutorService initPool = Executors.newFixedThreadPool(INIT_THREADS_COUNT);

ExecutorService initPool = Executors.newFixedThreadPool(Math.min(INIT_THREADS_COUNT, providers.size()));

chrfwow · 2025-07-01T08:34:12Z

src/main/java/dev/openfeature/sdk/multiprovider/MultiProvider.java

+                throw new GeneralError("init failed");
+            }
+        }
+        metadataName = json.toString();


If the executer service is unused from this point onwards, we should shut it down

chrfwow · 2025-07-01T08:40:02Z

src/test/java/dev/openfeature/sdk/multiProvider/MultiProviderTest.java

+        assertThrows(FlagNotFoundError.class, () -> finalMultiProvider1.getStringEvaluation("non-existing", "", null));
+
+        multiProvider.shutdown();
+        multiProvider = new MultiProvider(providers, new FirstSuccessfulStrategy());


There should probably be a test file with tests for each strategy. If you want to reduce code duplication by the flag setup, make those test classes extend some common test setup class

have created a BaseStrategyTest for the setup which is extended by the separate test classes for each strategy

codecov · 2025-07-01T08:47:58Z

Codecov Report

Attention: Patch coverage is 96.10390% with 3 lines in your changes missing coverage. Please review.

Project coverage is 93.41%. Comparing base (cbf7a58) to head (5810779).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...v/openfeature/sdk/multiprovider/MultiProvider.java	94.64%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1500      +/-   ##
============================================
+ Coverage     92.81%   93.41%   +0.60%     
- Complexity      486      518      +32     
============================================
  Files            46       50       +4     
  Lines          1169     1246      +77     
  Branches        103      112       +9     
============================================
+ Hits           1085     1164      +79     
+ Misses           54       51       -3     
- Partials         30       31       +1

Flag	Coverage Δ
unittests	`93.41% <96.10%> (+0.60%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

suvaidkhan · 2025-07-03T08:19:08Z

Looks good so far! I'm not sure if we want to add a json dependecy (which might also produce the License Compliance error) "just" so that we can build up the metadata name string.

Should I construct the json using Strings?

chrfwow · 2025-07-03T11:04:23Z

Maybe it would be worth it.
@toddbaert what do you think?

suvaidkhan · 2025-07-08T18:40:54Z

@chrfwow @toddbaert any updates on this?

aepfli

Thank you, great effort. I am looking forward to having the multiprovider migrated. For me, the added dependency is currently a show stopper, because I think we can handle that with proper and simple data classes, even with better metadata support overall (not losing information from the sub providers). I added simple but untested code snippets to my review. Please let me know what you think about this approach.

aepfli · 2025-07-09T05:20:01Z

src/main/java/dev/openfeature/sdk/multiprovider/MultiProvider.java

+    public static final int INIT_THREADS_COUNT = 8;
+    private final Map<String, FeatureProvider> providers;
+    private final Strategy strategy;
+    private String metadataName;


[suggestion] as this variable is more than just a name - it is a json object, we might want to rename it to something more representing like

Suggested change

private String metadataName;

private String metadata;

aepfli · 2025-07-09T05:34:20Z

src/main/java/dev/openfeature/sdk/multiprovider/MultiProvider.java

+     */
+    @Override
+    public void initialize(EvaluationContext evaluationContext) throws Exception {
+        JSONObject json = new JSONObject();


[nit] If this is really the only reason why we add a JSON dependency, can we maybe utilize our own object representation of metadata?

something like

@Override public void initialize(EvaluationContext evaluationContext) throws Exception { var metadataBuilder = MultiProviderMetadata.builder(); metadataBuilder.name(NAME); Map<String, Metadata> providersMetadata = new HashMap(); ExecutorService initPool = Executors.newFixedThreadPool(INIT_THREADS_COUNT); Collection<Callable<Boolean>> tasks = new ArrayList<>(providers.size()); for (FeatureProvider provider : providers.values()) { tasks.add(() -> { provider.initialize(evaluationContext); return true; }); Metadata providerMetadata = provider.getMetadata(); providersMetadata.put(providerMetadata.getName(), providerMetadata); } metadataBuilder.originalMetadata(providersMetadata); List<Future<Boolean>> results = initPool.invokeAll(tasks); for (Future<Boolean> result : results) { if (!result.get()) { throw new GeneralError("init failed"); } } metadata = metadataBuilder.build(); }

with an own implementation of the metadata interface called MultiProviderMetadata

@Data @Builder public class MultiProviderMetadata implements Metadata { String name; Map<String, Metadata> originalMetadata; }

wdyt? This would eliminate the dependency and make editing the code easier - I did not test this, and I am not sure if we will miss information with JSON conversion, etc.

The getMetaData function is supposed to return a String, what should I be returning in this implementation?

I think you can just return the metadata object.

@Override public Metadata getMetadata() { return metadata; }

There is no need for the lambda anymore :)

Why are we using this map - Map<String, Metadata> originalMetadata; again?
MetaData will only contain one field that is the name right?

For the Multiprovider it is different. Ideally the metadata contains all the metadata of each provider too. So this map will contain for each sub provider the metadata

I'm getting - may expose internal representation on Spotbugs for getMetaData.
Was thinking of creating a defensive copy in getMetaData, something like this -

public Metadata getMetadata() { if (metadata == null) { return null; } Map<String, Metadata> defensiveCopy = metadata.getOriginalMetadata() == null ? null : Map.copyOf(metadata.getOriginalMetadata()); return MultiProviderMetadata.builder() .name(metadata.getName()) .originalMetadata(defensiveCopy) .build(); }

Is this acceptable ?

to be honest, i think we should ignore this spotbugs warning

suvaidkhan · 2025-07-10T03:30:13Z

Thank you, great effort. I am looking forward to having the multiprovider migrated. For me, the added dependency is currently a show stopper, because I think we can handle that with proper and simple data classes, even with better metadata support overall (not losing information from the sub providers). I added simple but untested code snippets to my review. Please let me know what you think about this approach.

Looks good to me.
I'll add these changes and some UTs to make sure it's working correctly.

Signed-off-by: suvaidkhan <[email protected]>

… removed json dep Signed-off-by: suvaidkhan <[email protected]>

chrfwow

Looks good

chrfwow · 2025-07-17T06:31:49Z

src/main/java/dev/openfeature/sdk/multiprovider/MultiProvider.java

+        List<Future<Boolean>> results = initPool.invokeAll(tasks);
+        for (Future<Boolean> result : results) {
+            if (!result.get()) {
+                throw new GeneralError("init failed");


We also need to shut down the executer service in this case

chrfwow · 2025-07-17T06:40:52Z

src/test/java/dev/openfeature/sdk/multiProvider/MultiProviderTest.java

+        Strategy mockStrategy = mock(Strategy.class);
+        MultiProvider multiProvider = new MultiProvider(providers, mockStrategy);
+        multiProvider.initialize(null);
+        assertNotNull(multiProvider);


This assert is a NO-OP

Suggested change

assertNotNull(multiProvider);

Signed-off-by: suvaidkhan <[email protected]>

…port' into suvaidkhan/add-multiprovider-support

sonarqubecloud · 2025-07-17T22:53:39Z

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

suvaidkhan · 2025-07-22T06:03:55Z

Hey @aepfli @chrfwow this is ready for review

aepfli

Thank you, the basic implementation looks good to me. But i took a closer look at the two strategies. The strategies seem to be a little inconsistent in exception handling, logging and returning. I think we should normalize this a little for consistency (no need for more abstraction, but it should log the same way, it should handle all the possible exceptions the same way, etc).

aepfli · 2025-07-23T13:00:04Z

src/test/java/dev/openfeature/sdk/multiProvider/MultiProviderTest.java

+        Strategy mockStrategy = mock(Strategy.class);
+        MultiProvider multiProvider = new MultiProvider(providers, mockStrategy);
+        multiProvider.initialize(null);
+        assertNotNull(multiProvider);


Suggested change

assertNotNull(multiProvider);

aepfli · 2025-07-23T13:02:27Z

src/main/java/dev/openfeature/sdk/multiprovider/MultiProvider.java

+        var metadataBuilder = MultiProviderMetadata.builder();
+        metadataBuilder.name(NAME);
+        HashMap<String, Metadata> providersMetadata = new HashMap<>();
+        ExecutorService initPool = Executors.newFixedThreadPool(Math.min(INIT_THREADS_COUNT, providers.size()));


Suggested change

ExecutorService initPool = Executors.newFixedThreadPool(Math.min(INIT_THREADS_COUNT, providers.size()));

ExecutorService executorService = Executors.newFixedThreadPool(Math.min(INIT_THREADS_COUNT, providers.size()));

initPool seems odd, we should properly name it, and i suggest to name it executorService

aepfli · 2025-07-23T13:04:36Z

src/main/java/dev/openfeature/sdk/multiprovider/FirstMatchStrategy.java

+                    return res;
+                }
+            } catch (FlagNotFoundError e) {
+                log.debug("flag not found {}", e.getMessage());


Suggested change

log.debug("flag not found {}", e.getMessage());

log.debug("flag not found {}", key, e);

The exception might have a different message, hence i think adding the key is worth it, as a separate infomration. Additionally most logging frameworks allow you to add the exception as an additional parameter, which will print the stacktrace if available. It is just a good practice

aepfli · 2025-07-23T13:05:14Z

src/main/java/dev/openfeature/sdk/multiprovider/FirstMatchStrategy.java

+                log.debug("flag not found {}", e.getMessage());
+            }
+        }
+        throw new FlagNotFoundError("flag not found");


If we throw an exception here i suggest to add the key

Suggested change

throw new FlagNotFoundError("flag not found");

throw new FlagNotFoundError("flag '" + key + "' not found");

but it would be better to construct a ProviderEvaluation object with an ErrorCode. we do not use the exception for flow control, our SDK will also handle this properly.

aepfli · 2025-07-23T13:11:04Z

src/main/java/dev/openfeature/sdk/multiprovider/FirstSuccessfulStrategy.java

+            }
+        }
+
+        throw new GeneralError("evaluation error");


We should be consistent in our Exceptions/return-values - we should construct a ProviderEvaluation with an error code, and the error code should be consistent for all Strategies

Yes this makes sense, I'll make these changes and raise a PR soon

suvaidkhan requested review from a team as code owners July 1, 2025 07:43

suvaidkhan force-pushed the suvaidkhan/add-multiprovider-support branch from 8710a52 to f07dd25 Compare July 1, 2025 07:46

chrfwow requested changes Jul 1, 2025

View reviewed changes

aepfli reviewed Jul 9, 2025

View reviewed changes

suvaidkhan added 2 commits July 16, 2025 19:06

MultiProvider: Added strategies, unit tests and documentation

58c308c

Signed-off-by: suvaidkhan <[email protected]>

MultiProvider: Added MultiProviderMetadata.java, refactored tests and…

1103949

… removed json dep Signed-off-by: suvaidkhan <[email protected]>

suvaidkhan force-pushed the suvaidkhan/add-multiprovider-support branch from 97f6dc9 to 1103949 Compare July 17, 2025 00:07

Merge branch 'main' into suvaidkhan/add-multiprovider-support

4e380c6

chrfwow reviewed Jul 17, 2025

View reviewed changes

suvaidkhan added 2 commits July 17, 2025 17:50

Multiprovider: review comments incorporated

dae672e

Signed-off-by: suvaidkhan <[email protected]>

Merge remote-tracking branch 'origin/suvaidkhan/add-multiprovider-sup…

5810779

…port' into suvaidkhan/add-multiprovider-support

suvaidkhan requested review from aepfli and chrfwow July 18, 2025 23:24

aepfli reviewed Jul 23, 2025

View reviewed changes

	ExecutorService initPool = Executors.newFixedThreadPool(INIT_THREADS_COUNT);
	ExecutorService initPool = Executors.newFixedThreadPool(Math.min(INIT_THREADS_COUNT, providers.size()));

	ExecutorService initPool = Executors.newFixedThreadPool(Math.min(INIT_THREADS_COUNT, providers.size()));
	ExecutorService executorService = Executors.newFixedThreadPool(Math.min(INIT_THREADS_COUNT, providers.size()));

	log.debug("flag not found {}", e.getMessage());
	log.debug("flag not found {}", key, e);

	throw new FlagNotFoundError("flag not found");
	throw new FlagNotFoundError("flag '" + key + "' not found");

feat: Add multi-provider support #1500

Are you sure you want to change the base?

feat: Add multi-provider support #1500

Uh oh!

Conversation

suvaidkhan commented Jul 1, 2025

This PR

Related Issues

Follow-up Tasks

Uh oh!

chrfwow left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

suvaidkhan commented Jul 3, 2025

Uh oh!

chrfwow commented Jul 3, 2025

Uh oh!

suvaidkhan commented Jul 8, 2025

Uh oh!

aepfli left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aepfli Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

suvaidkhan Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

suvaidkhan commented Jul 10, 2025

Uh oh!

chrfwow left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented Jul 17, 2025

Quality Gate passed

Uh oh!

suvaidkhan commented Jul 22, 2025

Uh oh!

aepfli left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrfwow left a comment •

edited

Loading

codecov bot commented Jul 1, 2025 •

edited

Loading

aepfli Jul 9, 2025 •

edited

Loading

suvaidkhan Jul 14, 2025 •

edited

Loading