Handling incorrect UnleashClient configuration about unleash-client-dotnet HOT 18 CLOSED

Hi @daveleek, thank you for your InstanceTag suggestion and the 2.5.0 release from your team. We have implemented both of them, and they are working flawlessly now.
We appreciate your support and the efficiency with which your team addressed our needs.

Take care,
Xiaoyang

from unleash-client-dotnet.

Thank you @xiaoyangwang-geotab, prod vs local shouldn't behave differently in that regard!
Thanks for the code snippet, I'll have a look!

from unleash-client-dotnet.

Hi @sighphyre, thank you for explaining the concept of tolerance to failure. I do understand the design, and It worked well while I was testing it.

However, I have a concern regarding the initialization of the unleash instance. In the event that someone enters the wrong API token in the config (which could happen in reality), how can we determine if the unleash configuration is incorrect? Even if everything is configured correctly and the unleash instance is created successfully, how can we know if the unleash server is down? We may not necessarily encounter an exception, but we would like to have a property or some indicator that indicates when something is going wrong.

Generally, I think our concern is that we want to be notified of any failures directly from the unleash instance instead of having to rely on logs.

Thanks!

from unleash-client-dotnet.

Hello @xiaoyangwang-geotab!

Have you found a solution to your question yet?
There should be an error thrown if the http request to fetch toggles fails. Incorrect token - is that a token-code that does not exist/or a typo? Or do you mean an existing token, but wrong type of token/token that doesn't have access to the configured project?

David

from unleash-client-dotnet.

Hi @daveleek

Thank you for your response. Unfortunately, I have not been able to find a solution to the issue at this time.

I have attempted to use a non-existent token, as well as an admin token in the client, but neither of them resulted in the expected exception being thrown. Here is the section of code where I initialize my Unleash instance:

      var settings = new UnleashSettings()
       {
           AppName = appName,
           UnleashApi = new Uri(apiUri),
           CustomHttpHeaders = new Dictionary<string, string>(StringComparer.InvariantCulture)
           {
               { "Authorization", apiToken } // The apiToken should only be the client token specified for production or development. Neither admin tokens nor personal access tokens will work.
           },
       };
       var unleashFactory = new UnleashClientFactory();
       var unleash = unleashFactory.CreateClient(settings, synchronousInitialization: true);

By the way, I am currently running the code on a local server. Not sure if there're differences between the behavior of the code on a production server and a local server regarding this issue.

Thanks!

from unleash-client-dotnet.

Hey @xiaoyangwang-geotab. So it turns out if you set log level to Verbose then error messages should appear in the log. We're looking into it for a future improvement, but the knowledge should at least enable you to see error messages from API calls.

from unleash-client-dotnet.

Thanks @daveleek So how to set the log level to Verbose? Additionally, if an error is logged, I can review the log within the code to identify any failures. Is that what you meant?

from unleash-client-dotnet.

Hi @xiaoyangwang-geotab

So how to set the log level to Verbose?

that depends on your logging framework of choice. in my repro I used Serilog and the console sink:

    using var log = new LoggerConfiguration()
    .MinimumLevel.Verbose() // Setting to Verbose here
    .WriteTo.Console()
    .CreateLogger();

Additionally, if an error is logged, I can review the log within the code to identify any failures. Is that what you meant?

Setting log level to Verbose should make the error messages appear in the log output of your application. It will not raise exceptions that stops execution though, it runs in a background timer/thread

from unleash-client-dotnet.

Thanks @daveleek

Unfortunately, this is not what we are looking for. Enabling verbose logging would generate excessive noise, and implementing log checks within the code would introduce unnecessary overhead, which is also not desirable.

Does your team have any plans to improve this feature? Thanks!

from unleash-client-dotnet.

Hey @xiaoyangwang-geotab, I realise I'm super late to this thread, apologies.

Just want to unpack this one a little, so the philosophy of the Unleash SDKs is that they should be tolerant to failure and not impact their hosting application in the case of errors. To this end, the behaviour here is that the SDKs shouldn't need to be able to sync to Unleash to work correctly, it should have a backup file saved from the last time they synced to Unleash and they should sync as soon as it's able to reach Unleash. This is important here because if an API key is revoked in the Unleash UI, the SDK should be able to continue to work against its backup file.

I realise this isn't your problem, I'm just trying to provide some context on why the SDK works the way it does. That being said, I'm not sure I correctly understand the problem here, is there a reason why you can't set the token correctly here? What are you actually trying to solve?

We're more than open to trying to resolve the issue but I'm not 100% confident yet that bubbling the underlying exception is the correct behaviour here.

from unleash-client-dotnet.

Hi @xiaoyangwang-geotab. So what we've discussed and started working on is to add an error-callback to the event emitting configured with the ConfigureEvents method on the IUnleash interface (and on the DefaultUnleash instance).

from unleash-client-dotnet.

Sounds good! Thank you @daveleek.

Also, I have a couple of questions regarding how retrying works. I would like to understand the scenarios below:

1. Incorrect configuration (e.g., non-existing token): In this situation, the unleash instance could be initialized, but with empty feature toggles. Is it possible to correct the configuration and apply the changes without restarting our application?

2. Unleash server is down during initialization: In this situation, an exception would be thrown. Is there a retry policy implemented for such cases?

Thanks!

from unleash-client-dotnet.

1. Incorrect configuration ... Is it possible to correct the configuration and apply the changes without restarting our application?

Once the settings have been added to the Unleash SDK instance they're handed over to the internal services needing them, and are hard to replace on the instance itself.

Unleash is typically (and we really recommend this) configured as a singleton, so you'd have to dispose the whole instance of it first and then start up a new one, and if you're using Dependency Injection you'd need to find a way to replace the singleton in the container.

2. Unleash server is down during initialization: In this situation, an exception would be thrown. Is there a retry policy implemented for such cases?

If Unleash is initialized with synchronousInitialization: true, then no. It will crash and there's no retries.
If Unleash is initialized with synchronousInitialization: false then yes, Unleash will log exceptions but will retry on interval as configured (FetchTogglesInterval) and will recover on retry after Unleash instance comes online.

from unleash-client-dotnet.

Thanks @daveleek

I have a couple more questions that extend from the second question I asked earlier:

1. If Unleash is initialized with synchronousInitialization: false, would we also be able to determine if the server is down from the error callback?
2. In the event of a server outage during initialization, would the Unleash instance still read feature toggles from backup files generated during the last successful initialization or fetching?
   We attempted to save the backup files outside of the container and use them when the Unleash instance is initialized with empty toggles (which would have the error callback indicates an issue in your future implementation). However, the problem we encountered is that each initialization creates a new backup file, making it difficult to manage. This is likely why the default backup file location is the temporary folder. Is there a more effective approach to handle this situation?

Thank you very much for your help.

from unleash-client-dotnet.

Hi @xiaoyangwang-geotab!

1. If Unleash is initialized with synchronousInitialization: false, would we also be able to determine if the server is down from the error callback?

Yes. We are adding information to the event in the callback that should enable you to determine if the server is down, up, or returning odd statuses.

2. In the event of a server outage during initialization, would the Unleash instance still read feature toggles from backup files generated during the last successful initialization or fetching? ... Is there a more effective approach to handle this situation?

Yeah I had a look at this to understand why it would be doing this - the backup file should always be restorable. Have you set the InstanceTag property on the UnleashSettings when you're initializing Unleash? If not then this property is set to a random value, this value is also added to the backup file name. If you set the InstanceTag then the file name will be consistent across restarts and should work with backup files being mounted back in.

Another option is to look at bootstrapping unleash

from unleash-client-dotnet.

We have now released the 2.5.0 update which brings the option of registering a callback to be notified of errors occurring in the Unleash SDK. It has been added to the event handling registration callback

from unleash-client-dotnet.

Thanks for the feedback @xiaoyangwang-geotab!

from unleash-client-dotnet.

Good to hear, thank you @xiaoyangwang-geotab!

from unleash-client-dotnet.