The tool attempts to release many crates too rapidly

[ilyvion]

error: failed to publish to registry at https://crates.io

Caused by:
  the remote server responded with an error (status 429 Too Many Requests): You have published too many crates in a short period of time. Please try again after Thu, 30 Jun 2022 15:07:44 GMT or email [email protected] to have your limit increased.

[epage]

Huh, never ran across this. Out of curiosity, how many did you release?

Now to figure out what the rate limits are so we can stay inside of them ...

[ilyvion]

It was 7 crates, that message came on the fifth one.

[epage]

Huh, I think I've exceeded that limit with clap.

[ilyvion]

I sent an e-mail to [email protected] and got this response; maybe it can help you figure out how to rate limit appropriately:

The rate limit for creating new crates is 1 crate every 10 minutes, with a burst of 5 crates.

The rate limit for new versions of existing crates is 1 per minute, with a burst of 30 crates, so when releasing new versions of these crates, you shouldn't hit the limit.

It's not particularly secret, we just don't publish it other than in the code because it's subject to change. The responses from the rate limited requests on when to try again contain the most accurate information.

[epage]

@alexschrod were you releasing new crates?

[ilyvion]

@epage Yeah.

[epage]

We need to tread carefully with this so people don't just ctrl-c cargo-release and end up in a similar situation

[ilyvion]

I intended to release all these crates (the workspace is 7 separate crates that go together), but I wasn't aware of the low burst limit until I first tried running this tool. Mostly because I'm lazy and didn't want to have to manually run cargo publish 7 times. As evidenced by the response I got, I will not be having this issue when doing new releases, since the burst for that is 30 rather than 5.

[epage]

Yes, this is more of a concern for the initial release, so it can be worked around which lowers its priority.

[epage]

In considering this, I feel like the needed sleep times would be unacceptable for a user to sit at the program waiting, so I'm just adding an error check for this situation. We can further refine this over time.