Customizable Azure API retry behavior

[bryanburke]

Is your feature request related to a problem? Please describe.
N/A

Describe the solution you'd like
If possible, I think it would be helpful to be able to customize the Azure API call retry behavior via Steampipe Azure plugin configuration. For example, the following settings might be exposed via azure.spc:

1. Maximum retries.
2. Minimum delay between retries (e.g., the starting delay for an exponential backoff).

Describe alternatives you've considered
N/A

Additional context
Azure provides the following documentation regarding retry behavior in the Azure SDK for Go:

• https://docs.microsoft.com/en-us/azure/developer/go/azure-sdk-core-concepts#http-pipeline-flow
• https://docs.microsoft.com/en-us/azure/developer/go/azure-sdk-core-concepts#core-http-pipeline-policies

[rajlearner17]

@bryanburke Thanks for using Steampipe!!
Appreciate this suggestion; we are acknowledging to look into it.

We have implemented this in AWS, in case that helps you.

Below are reference codes used in AWS

AWS Plugin config file

service.go

Sample use

[github-actions]

'This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.'

[cbruno10]

Not stale, PR currently under review.

[github-actions]

'This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.'

[cbruno10]

Not stale, PR is still under review.

[github-actions]

'This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.'

[github-actions]

'This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.'

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[bigdatasourav]

Hello @bryanburke, please accept my apologies for the delayed response.

We have utilized the autorest package in this plugin, which offers API retry support through the RetryAttempts and RetryDuration parameters. By default, the RetryAttempts parameter is set to 3, and the RetryDuration parameter is set to 30 seconds.

We have tested the retry logic, but the exponential backup logic is not working correctly; here is a sample log output -

# with RetryAttempts 9 & minRetryDuration-25ms
[INFO]  1686572651622: attempt: 0
 12:24:11.810 UTC   1686572651622: delay: 0s
 12:24:11.810 UTC   1686572651622: attempt: 1
 12:24:11.810 UTC   1686572651622: delay: 0s
 12:24:11.811 UTC   1686572651622: attempt: 2
 12:24:11.811 UTC   1686572651622: delay: 0s
 12:24:11.811 UTC   1686572651622: attempt: 3
 12:24:11.811 UTC   1686572651622: delay: 0s
 12:24:11.811 UTC   1686572651622: attempt: 4
 12:24:11.811 UTC   1686572651622: delay: 0s
 12:24:11.811 UTC   1686572651622: attempt: 5
 12:24:11.812 UTC   1686572651622: delay: 0s
 12:24:11.812 UTC   1686572651622: attempt: 6
 12:24:11.812 UTC   1686572651622: delay: 1s
 12:24:12.817 UTC   1686572651622: attempt: 7
 12:24:12.817 UTC   1686572651622: delay: 3s
 12:24:15.820 UTC   1686572651622: attempt: 8
 12:24:15.821 UTC   1686572651622: delay: 6s
 12:24:21.824 UTC   1686572651622: attempt: 9
 1686572651622: delay: 12s

Also, they have deprecated the autorest package so that no future support will be available on this package. Instead, they recommended using the azcore retry logic available in the Azure SDK.
To implement the azcore retry logic, we have to update the authentication process design and API calls. This will be a breaking change and time taking approach. While we prefer to transition to the new SDK and leverage its enhanced retry customizations, we have decided to defer this move for the time being.

[cbruno10]

Re-opening issue as this could still be helpful to the plugin.

In the linked PR, #491, I think the changes were implemented with the Steampipe plugin SDK’s RetryConfig instead of setting it in the Azure client, which may be why we were seeing some unexpected behaviour in test results above.

I think a reasonable approach would be to add some config args initially that are compatible with those in the autorest package (https://github.com/Azure/go-autorest/blob/33e12ab7683c1c236a863ccfbfdd78c626f7fe28/autorest/client.go#L168-L173) and those in the new azcore’s RetryOptions as well (https://github.com/Azure/azure-sdk-for-go/blob/05a959d4cf98a98bc99fb154b9f2ad1c8dd16072/sdk/azcore/policy/policy.go#L92), to give users some control over retries before we migrate the plugin to the new SDK.