search

Azure / apiops

APIOps applies the concepts of GitOps and DevOps to API deployment. By using practices from these two methodologies, APIOps can enable everyone involved in the lifecycle of API design, development, and deployment with self-service and automated tools to ensure the quality of the specifications and APIs that they’re building.
https://azure.github.io/apiops
MIT License
329 stars 193 forks source link

[FEATURE REQ] Handle 429 responses in the extractor without failing the whole process #612

Closed DSpirit closed 3 months ago

DSpirit commented 3 months ago

Please describe the feature.

As an API Operator, I want to extract many API's (more than 200), backends, tags etc. without getting 429 exceptions that break the process completely.

Running such big operations, I often experience results like: SubscriptionRequestsThrottled with error messages as follows: System.Net.Http.HttpRequestException: HTTP request to URI https://management.azure.com/subscriptions/***/resourceGroups/***/providers/Microsoft.ApiManagement/service/***/apiVersionSets/***?api-version=2023-09-01-preview failed with status code 429. Content is '{"error":{"code":"SubscriptionRequestsThrottled","message":"Number of 'read' requests for subscription actor '***:***' exceeded. Please try again after '1' seconds after additional tokens are available. Refer to https://aka.ms/arm-throttling for additional information."}}'.

Here's a simple PR that worked for me: https://github.com/Azure/apiops/pull/611

Feedback is welcome, my internal test ran successfully (within the first try!).

github-actions[bot] commented 3 months ago 
  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.