Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raise rate limit of particular crates? owners? for many versions of a crate per day #6336

Open
carols10cents opened this issue Apr 14, 2023 · 2 comments
Labels
A-backend ⚙️ C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works

Comments

@carols10cents
Copy link
Member

carols10cents commented Apr 14, 2023

Currently, we have a global limit on the number of versions of a crate that can be published in one day, and the environment variable is currently set to 10 in production.

This covers 99.8% of crates, but we've recently had one case in the 0.2%: a crate that has ~30 0.x.0 releases that are all supported, and a fix that needed to be backported and published as 30 new 0.x.1 versions.

The current workaround is for the owner to contact us, we raise the global env var value for everyone to a value that would let them publish all the versions needed in one day, then contact us again when they're done and we return the env var to its original version. This works but is a lot of coordination and opportunities for mistakes.

A better solution would be if a trusted owner (user? team?) could contact us and request a more permanent higher limit, so that they don't have to contact us again every time they need to publish many versions in a day. We currently have the ability to increase the burst of publishes of new crates per-user, and the ability to increase the max_upload_size per-crate. It's not clear if this limit exception could somehow be folded into either of those systems or if a new system is needed just for this or if all need to be refactored into a new system.... details left as an exercise for the implementer 😂

For searchability, the error message you currently get when hitting this limit is "You have published too many versions of this crate in the last 24 hours".

@carols10cents carols10cents converted this from a draft issue Apr 14, 2023
@carols10cents carols10cents changed the title Raise rate limit of crates? owners? for many versions of a crate per day Raise rate limit of particular crates? owners? for many versions of a crate per day Apr 14, 2023
@Turbo87 Turbo87 added C-internal 🔧 Category: Nonessential work that would make the codebase more consistent or clear A-backend ⚙️ labels Apr 25, 2023
@Turbo87
Copy link
Member

Turbo87 commented Aug 3, 2023

I guess #6875 has resolved that? feel free to reopen is I misinterpreted this :)

@Turbo87 Turbo87 closed this as completed Aug 3, 2023
@carols10cents
Copy link
Member Author

Reopening, sorry I didn't realize this at the time you closed this -- no, the MAX_NEW_VERSIONS_DAILY/new_version_rate_limit is still global:

if let Some(daily_version_limit) = app.config.new_version_rate_limit {
let published_today = count_versions_published_today(krate.id, conn)?;
if published_today >= daily_version_limit as i64 {
return Err(custom(
StatusCode::TOO_MANY_REQUESTS,
"You have published too many versions of this crate in the last 24 hours",
));
}
}

@carols10cents carols10cents reopened this Aug 8, 2024
@Turbo87 Turbo87 removed their assignment Aug 8, 2024
@Turbo87 Turbo87 added C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works and removed C-internal 🔧 Category: Nonessential work that would make the codebase more consistent or clear labels Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-backend ⚙️ C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works
Projects
Archived in project
Development

No branches or pull requests

2 participants