Spec: a4ffec3
See: open-feature/dotnet-sdk#126
The spec allows a single instance of a provider to be bound to multiple names (even if it didn't allow this, any naive implementation would probably allow it to happen). We either need to prevent it or specify how it should work. We may want to specify that providers that are still bound to any client name are not shut down. - @toddbaert
I consider this a spec bug personally, because it constitutes a problematic ambiguity in the spec. - @toddbaert
cc @justinabrahms
Quote from @kinyoklion 👍
Basic case.
var provider1 = new TestProvider();
openFeature.SetProvider("a", provider1);
// Call init on provider1?
openFeature.SetProvider("a", new TestProvider());
// Call shutdown on provider 1?
// Call init on new provider.
Two Names Scenario 1.
var provider = new TestProvider();
openFeature.SetProvider("a", provider);
// Call init on provider?
openFeature.SetProvider("b", provider);
// Provider already has init called. Do we call it again?
Two Names Scenario 2.
var provider1 = new TestProvider();
openFeature.SetProvider("a", provider1);
openFeature.SetProvider("b", provider1);
openFeature.SetProvider("b", new TestProvider());
// We don't want to shutdown provider1, because it is still registered to "b".
Spec: a4ffec3
See: open-feature/dotnet-sdk#126
The spec allows a single instance of a provider to be bound to multiple names (even if it didn't allow this, any naive implementation would probably allow it to happen). We either need to prevent it or specify how it should work. We may want to specify that providers that are still bound to any client name are not shut down. - @toddbaert
I consider this a spec bug personally, because it constitutes a problematic ambiguity in the spec. - @toddbaert
cc @justinabrahms
Quote from @kinyoklion 👍