Summary
When using the .NET SDK in Consumer mode with Redis as the cache adapter, the SDK key passed to is never validated or used. Any string — including an obviously invalid or fake key — works without errors. However, the constructor still requires an SDK key parameter, even though the SDK never contacts Split Cloud in this mode.
This creates confusion for developers and suggests the API surface may not accurately reflect the behavior of Consumer + Redis mode
Environment
- SDK: splitio-dotnet-client
- Version: 7.13.0
- Mode: Consumer
- Cache Adapter: Redis
- Redis Source: Split Synchronizer populating Redis
- .NET Version: 8
- OS: Windows
Code Sample
This code works perfectly even with a fake apikey
static async Task Main(string[] args)
{
var cacheAdapterConfig = new CacheAdapterConfigurationOptions
{
Type = AdapterType.Redis,
Host = "localhost",
Port = "6379"
};
var splitConfig = new ConfigurationOptions
{
Mode = Mode.Consumer,
CacheAdapterConfig = cacheAdapterConfig
};
// Any string works here — even an invalid or fake key
var factory = new SplitFactory("*** ANY APIKEY WORKS ***", splitConfig);
var client = factory.Client();
client.BlockUntilReady(10000);
var treatment = await client.GetTreatmentAsync("user@test.com", "flag1");
}
Expected Behavior
Please consider adding an overloaded constructor to the SplitFactory class like this:
var factory = new SplitFactory(splitConfig);
Summary
When using the .NET SDK in Consumer mode with Redis as the cache adapter, the SDK key passed to is never validated or used. Any string — including an obviously invalid or fake key — works without errors. However, the constructor still requires an SDK key parameter, even though the SDK never contacts Split Cloud in this mode.
This creates confusion for developers and suggests the API surface may not accurately reflect the behavior of Consumer + Redis mode
Environment
Code Sample
This code works perfectly even with a fake apikey
Expected Behavior
Please consider adding an overloaded constructor to the
SplitFactoryclass like this: