A developer writes a C# library that wraps HttpClient to call the Dataverse Web API for a high-volume integration. The developer wants a reusable retry policy for service protection errors. Which policy design follows Microsoft guidance?
Select an answer to reveal the explanation.
Short Explanation
A good retry policy listens to the server. When Dataverse says "come back in 30 seconds," you come back in 30 seconds, and if it doesn't say, you back off a little more each time. Hammering away every 100 ms just makes the wait longer.
Full Explanation
Microsoft's sample Web API service library uses a Polly retry policy that handles transient HTTP errors and 429 Too Many Requests. For each retry, the sleep duration is taken from the Retry-After header when present, and otherwise falls back to an exponential backoff based on the attempt count, with a configurable maximum number of retries. This design respects the server's signal, avoids extending the throttling window and still copes with transient failures that do not include a header. Waiting a fixed 100 milliseconds ignores Retry-After, sends repeated demanding traffic while the user is throttled, and causes Dataverse to lengthen the retry duration; an unbounded retry count also risks infinite loops. Retrying on 401 and 403 targets authentication and authorization failures, which retries cannot fix; they need a valid token or correct security roles, and the policy would miss the 429 responses that matter. Creating a new HttpClient for each attempt does not bypass service protection limits, because they are evaluated per user, and it wastes sockets; the HttpClient should be reused. Exam caveat: Microsoft recommends gradually increasing the request rate and letting Retry-After control pacing, rather than precomputing a safe rate. Operational check: simulate 429 responses with a Retry-After value in a test handler and confirm the policy waits that duration before resending.