Skip to content
This repository has been archived by the owner on Jul 12, 2023. It is now read-only.

Throttle bulk code issuance using server ratelimiter config #1128

Merged
merged 7 commits into from
Nov 19, 2020

Conversation

whaught
Copy link
Contributor

@whaught whaught commented Nov 18, 2020

Issue #1061

Proposed Changes

  • Look for the retry-after header on error response
  • if found, sleep as directed

Release Note

Throttle batches for bulk code issuance

@google-cla google-cla bot added the cla: yes Auto: added by CLA bot when all committers have signed a CLA. label Nov 18, 2020
@sethvargo
Copy link
Member

Alternative: instead of spreading load evenly we could burst up to remaining tokens and then sleep until the interval. Would make things faster for small CSVs that are under the count/interval. That's a little trickier because we'd actually need to peek into the ratelimiter (not just the config)

I would prefer this approach, but you don't need to peek into the limiter, look at the response headers. They'll include all the data you need 👍

@whaught
Copy link
Contributor Author

whaught commented Nov 18, 2020

Alternative: instead of spreading load evenly we could burst up to remaining tokens and then sleep until the interval. Would make things faster for small CSVs that are under the count/interval. That's a little trickier because we'd actually need to peek into the ratelimiter (not just the config)

I would prefer this approach, but you don't need to peek into the limiter, look at the response headers. They'll include all the data you need 👍

I just saw that we have X-Retry-After in the api doc, which is what I need for this

@mikehelmick
Copy link
Contributor

Alternative: instead of spreading load evenly we could burst up to remaining tokens and then sleep until the interval. Would make things faster for small CSVs that are under the count/interval. That's a little trickier because we'd actually need to peek into the ratelimiter (not just the config)

I would prefer this approach, but you don't need to peek into the limiter, look at the response headers. They'll include all the data you need 👍

I just saw that we have X-Retry-After in the api doc, which is what I need for this

one consideration with the consuming all of the realm's quota - it makes it so that online code distribution won't work during this. probably not a big deal

@@ -336,7 +336,7 @@ You can expect the following responses from this API:

- `412` - The client requested a precondition that cannot be satisfied.

- `429` - The client is rate limited. Check the `X-Retry-After` header to
Copy link
Contributor Author

@whaught whaught Nov 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would I remember my own code? 😝

Copy link
Member

@sethvargo sethvargo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@google-oss-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sethvargo, whaught

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@google-oss-robot google-oss-robot merged commit 25fcf84 into google:main Nov 19, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes Auto: added by CLA bot when all committers have signed a CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants