Azure/AppConfiguration-DotnetProvider

App Configuration outage shouldn't block application's startup when optional is true

Closed this issue · 5 comments

lissdy commented

This is a follow-up question for Azure/AppConfiguration#699

As region replication is not generally available yet, we are following Primary Store + Secondary Store pattern for high availability.

But found App Configuration outage may block the application's startup even when optional is true

Unhandled exceptions cause application crash which can result in crash loops as orchestrators attempt to restart the application

In this case, any AAC Primary Store or AAC Secondary Store outage would block application startup, which doesn't achieve the
high availability purpose.
App Configuration outage shouldn't block the application's startup when optional is true

avanigupta commented

Hello @lissdy, the comment you linked above is applicable only when optional is not true. This is because LoadAll method swallows exceptions related to AppConfig errors when optional is true (code).

So any App Configuration outage will not block the application's startup when optional is true.

lissdy commented

@avanigupta , appreciate your reply! Actually, I don't have a good way to emulate App Configuration outage.
I tried to update the app configuration endpoint from https://XXX.azconfig.io to https://XXX.azconfig.test, and found the application startup would be blocked even when the optional is true.

But I realized to emulate App Configuration outage, I should just dummy the App Configuration Name, update endpoint from https://XXX.azconfig.io to https://dummy.azconfig.io, and it works as expected.

  • 👍1
lissdy commented

Hey @avanigupta , sorry to reopen the issue. May I know is possible to swallow Azure.Identity.AuthenticationFailedException when Optional is true?
Otherwise, when trying to connect App Configuration via Managed Identity, any authentication exception may block the application startup as well. Thanks

avanigupta commented

The optional flag is meant to protect application startup from AppConfig related errors/outages. If there is an authentication error like 401 or 403, it will bubble up as RequestFailedException and we will swallow it during startup. This behavior is the same, regardless of the type of credentials used.

In what scenario do you see Azure.Identity.AuthenticationFailedException?

avanigupta commented

Hi @lissdy, please let me know if you need further assistance with this. Closing for now because this behavior is by design.