[QUERY] Location poller handling of 500 error incompatible with specs for OperationResults API. about azure-sdk-for-go HOT 3 OPEN

I've tried to track the logic in the .net SDK. but it's pretty hard to figure it out because it's very fragmented.

I think that it boils down to this:

https://github.com/Azure/azure-sdk-for-net/blob/c4418cd3e85f2e01a92b702414244647ff3695df/sdk/core/Azure.Core/src/Shared/OperationInternal.cs#L122C63-L122C79

and this for the failure case:
https://github.com/Azure/azure-sdk-for-net/blob/c4418cd3e85f2e01a92b702414244647ff3695df/sdk/core/Azure.Core/src/Shared/OperationInternal.cs#L237C12-L237C91

but I don't see any code that would not consider a 500 a terminal failure.

from azure-sdk-for-go.

I think the problem here is that we've conflated rules for retry with status codes we consider to be terminal failure. Off the cuff, what probably needs to happen is that for status codes that aren't terminal success, we let them be handled by the retry policy which, by default, will enforce a retry cap (need to experiment with this). We just have to ensure that we don't consider the underlying poller to be "done" in such cases.

from azure-sdk-for-go.

Ok it's more nuanced than that. For context, Poller[T].PollUntilDone() will exit IFF one of the following conditions is met.

• the HTTP transport fails (governed by the retry policy)
• the underlying poller reaches a terminal state
• the context expires/is canceled

Here is the sequence of events. This assumes the default retry policy is in play.

1. PollUntilDone calls underlying poller.Poll
2. Poll creates the request and sends it through the pipeline
3. Service returns 500, the retry policy retries the request until the cap is hit
4. 500 is returned to the underlying poller which is non-terminal
5. goto step 1

While we could augment the retry policy to tell PollUntilDone "my retry cap has been exceeded", it would tightly couple the two together which is not good (e.g. if the in-box retry policy has been replaced, now the logic is broken).

This might require updating PollUntilDone to exit after N number of transient status codes. This requires some care though as it will multiply with the number of retries from the retry policy. i.e. if the retry policy retries three times on 500, and PollUntilDone retries three times on 500, the total number of requests will be nine (with exponential back-off from the retry policy to boot).

from azure-sdk-for-go.