You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am anticipating that when extracting and publishing artifacts , especially when the number of resources that need to be exported and published are quite large, there is a potential of running into 429 (too many requests/rate limited) by APIM control plane or just being returned with API call errors because of the chance of overwhelming the control plane .
RFE: Can extractor and publisher support a sleep values (in milliseconds between successive api calls)
The text was updated successfully, but these errors were encountered:
Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.
@martin2176 - we make API calls with the Azure SDK's HttpPipeline. It already handles 429 responses and has a default set of retry options. We have a feature request to make those retry options configurable in ApiOps (#254), so I'll close this issue in favor of that one.
Please describe the feature.
I am anticipating that when extracting and publishing artifacts , especially when the number of resources that need to be exported and published are quite large, there is a potential of running into 429 (too many requests/rate limited) by APIM control plane or just being returned with API call errors because of the chance of overwhelming the control plane .
RFE: Can extractor and publisher support a sleep values (in milliseconds between successive api calls)
The text was updated successfully, but these errors were encountered: