Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Availability: Adds account-level read regions as effective preferred …
…regions when preferred regions is not set on client. (#4709) # Pull Request Template ## Problem Statement As of today, customers who do not configure `ApplicationPreferredRegions` or `ApplicationRegion` are pinned to either the hub region (in multi-write accounts) or the primary region (in single-write accounts). In outage scenarios, availability is scoped to just a single region and is not ideal (both reads/writes in multi-write accounts and reads in single-write multi-region accounts have their availability curbed to just the one region). Setting `ApplicationPreferredRegions` or `ApplicationRegion` as empty is not an opt-out of availability decision from the customer's perspective unless of course on the client a regional endpoint has been set. This PR aims to fix this issue when preferred regions is not set, and a global endpoint is set on the client. ## Approach taken in this PR The idea is to construct an _effective preferred region list_ and to rely on account-level read and account-level write regions for it. If there is client-perceived unavailability or account-level topology changes - then this _effective preferred regions list_ is reordered accordingly or reflects the account-level regions post a cached `DatabaseAccount` refresh in the SDK. There are also changes made to the flow which decides when `DatabaseAccount` refresh is triggered. The decision depends on a check whether the SDK has a different effective first preferred read / write region from the first account-level read / write region. ## Closing issues closes #4665 --------- Co-authored-by: Kiran Kumar Kolli <kirankk@microsoft.com> Co-authored-by: Nalu Tripician <27316859+NaluTripician@users.noreply.github.com> Co-authored-by: Debdatta Kunda <87335885+kundadebdatta@users.noreply.github.com>
- Loading branch information