Can I stop being rate limited for issue creation? #1692

martinwguy commented 2024年11月02日 11:11:17 +01:00

Comment

Hi! I'm working on scripts that download and upload issues to forgejo repos and keep getting stuff like

Creating new issue: putissues.sh fails to add binary attachments on disroot
Failed to create 'putissues.sh fails to add binary attachments on disroot':
curl: (22) The requested URL returned error: 429
NewIssue: "martinwguy" posted 14 issues in under 5 minutes: rate limited
curl failed with status 22

I mean, I've created a second user martinwguy2 to be able to carry on working, but if this could be disabled for me or made more permissive it would be nicer, as I sometimes (rarely) have to create over a hundred issues in one swoop.

"No" is an OK answer.

Thanks, fab platform

M

### Comment Hi! I'm working on scripts that download and upload issues to forgejo repos and keep getting stuff like Creating new issue: putissues.sh fails to add binary attachments on disroot Failed to create 'putissues.sh fails to add binary attachments on disroot': curl: (22) The requested URL returned error: 429 NewIssue: "martinwguy" posted 14 issues in under 5 minutes: rate limited curl failed with status 22 I mean, I've created a second user martinwguy2 to be able to carry on working, but if this could be disabled for me or made more permissive it would be nicer, as I sometimes (rarely) have to create over a hundred issues in one swoop. "No" is an OK answer. Thanks, fab platform M

matkoniecz commented 2024年11月21日 16:16:23 +01:00

have you considered having script run a bit slower and on such error to wait minute (or more or less) and retry?

have you considered having script run a bit slower and on such error to wait minute (or more or less) and retry?

martinwguy commented 2024年11月21日 18:02:14 +01:00

No. It's an idea if it becomes a problem but it already takes an age.
I just created martinwguy2 and carried on testing with that.

No. It's an idea if it becomes a problem but it already takes an age. I just created martinwguy2 and carried on testing with that.

joegasewicz commented 2026年01月12日 21:45:43 +01:00

When a user sets up a projects, he will generally create a lot of issues. So we have a few choices:

1. get the creation date of the project & if it's within a predefined time period, then let that author create many issues.
2. Decrease the rate limit wait time to a few seconds.

If you like one of these ideas, I can work on this issue...

When a user sets up a projects, he will generally create a lot of issues. So we have a few choices: 1. get the creation date of the project & if it's within a predefined time period, then let that author create many issues. 2. Decrease the rate limit wait time to a few seconds. If you like one of these ideas, I can work on this issue...

martinwguy commented 2026年01月12日 22:44:24 +01:00

Thanks for taking an interest. The scenario is an issue-downloading and uploading script. The peak rate of issue creation would be when someone has migrated a project and wants to duplicate the issues on top of that.

On the one hand, it's true that this is most likely to happen shortly after a migration or repo creation prior to uploading something from a local backup, yes.

However, something that made the script busy-wait and then eventually get served after a short delay would also be acceptable, say a second or some seconds, if that's enough to prevent the site being flooded with issue creations, or whatever it is that the current limiter avoids.

Blessings

M

Thanks for taking an interest. The scenario is an issue-downloading and uploading script. The peak rate of issue creation would be when someone has migrated a project and wants to duplicate the issues on top of that. On the one hand, it's true that this is most likely to happen shortly after a migration or repo creation prior to uploading something from a local backup, yes. However, something that made the script busy-wait and then eventually get served after a short delay would also be acceptable, say a second or some seconds, if that's enough to prevent the site being flooded with issue creations, or whatever it is that the current limiter avoids. Blessings M