azure-sdk-for-net
azure-sdk-for-net copied to clipboard
Azure
Prototype making DelayStrategy public
Attempts to unify the DelayStrategy into something that can be used in both LROs and custom Retry policies. For LROs, the delayHint is what, if anything, the user specified in the pollingInterval param of WaitForCompletion. For retry policy, the delayHint is null.
For LROs, the DelayStrategy will always be wrapped in the RetryAfterDelayStrategy. This is not the case for RetryPolicy. Reasoning is discussed in this comment.
API change check
APIView has identified API level changes in this PR and created following API reviews.
@JoshLove-msft I assume we want to track this separately so I opened an issue for it https://github.com/Azure/azure-sdk-for-net/issues/35373
All LRO strategies are currently wrapped with the RetryAfterStrategy which makes it so the Retry-After header is always applied and not overridable within a strategy passed to OperationPoller. Should users be able to override this for either LRO or retries?
@JoshLove-msft I've often wondered if the service has determine the best value to pass back. Some I've seen just return 10 (10s) and it seems rather random. Perhaps we don't make it incidentally easy to ignore it, but I wonder if the pipeline should at least make it possible if someone wrote their own retry policy to ignore it in case a better value works for their workload after their own investigation.
@JoshLove-msft not sure if you noticed these. They didn't show up as fatal Checks errors, but looks like something broke inadvertently:
@JoshLove-msft not sure if you noticed these. They didn't show up as fatal Checks errors, but looks like something broke inadvertently:
Hmm where are you seeing this?
@JoshLove-msft in the Files tab, not the Checks.
Seems to not be an issue anymore.
All LRO strategies are currently wrapped with the RetryAfterStrategy which makes it so the Retry-After header is always applied and not overridable within a strategy passed to OperationPoller. Should users be able to override this for either LRO or retries?
@JoshLove-msft I've often wondered if the service has determine the best value to pass back. Some I've seen just return 10 (10s) and it seems rather random. Perhaps we don't make it incidentally easy to ignore it, but I wonder if the pipeline should at least make it possible if someone wrote their own retry policy to ignore it in case a better value works for their workload after their own investigation.
We ended up not allowing users to use a value that is less than the service provided value. If we hear of legitimate use cases we can add this ability in the future.
Once this is merged, will need to update DownloadSharedSource.ps1 in AutoRest to remove the deleted shared source files.