[Network] Weird use for status code 429

[mcardosos]

Related to Azure/azure-sdk-for-go#588
When creating or updating subnets, it can happen that the API return status code 429 and a message clarifying that this is a retryable error, (unlike the normal use of 429 which means to many requests).
My guess is that doing the very same request later, it will succeed.
Still, it would be weird to include status code 429 as a valid code to retry for in the SDKs. Is it possible to include this status code with this message in the swagger to indicate it is safe to continue retrying?
@amarzavery @whiskeyjay @marstr @jhendrixMSFT

[mcardosos]

@jobatzil what do you think?

[jhendrixMSFT]

Any update here? This resulted in a real customer issue in the Go SDK . We were able to prescribe a workaround however we'd like to understand if this is a best practice.

[mcardosos]

poke @amarzavery

[kirthik]

@DeepakRajendranMsft - Could you please take a look at this issue?

[tombuildsstuff]

👋 @DeepakRajendranMsft @kirthik is there any update/expected timeline to fix this? :)

[liumichelle]

The fix for this in progress - TBD ETA

[DeepakRajendranMsft]

We are still working on this, sorry. we are evaluating that if we have 429 as a retryable error, it may break clients out there that have a special treatment for 429 since they might expect an exception from SDKs generated by us

[jhendrixMSFT]

Even with a Retry-After header in the response?

[mcardosos]

Little documentation on 429 usage. With this as context, I think 429 usage is not something that has to do with this repository. 429 needs a different treatment than other status codes when we are talking about retry strategies. Retry strategies live on each language SDK client runtime. This has been fixed on the go SDK runtime here.

[mcardosos]

Fixed for go here Azure/go-autorest#155