500 errors, skipped issue numbers when creating issues #743

I just created an issue (worked). Then I created a second one and got a 500 error.

Waited a bit and tried again and it worked but I saw that the previous attempt also worked.

(I’m not going to delete the dupliate issue so you can see it when looking into it.)

Interestingly, the previous issue was #10. The one after that was #14. Not sure where #11, #12, and #13 went.

Just opened another one after that it was correctly created with the correct number (#15).

Repo: https://codeberg.org/domain/app/issues

@fnetX Are you able to find the relevant logs for this 500 error?

There is a simple rate limit which is not gracefully displayed and returns err 500. This could be an issue, but I somehow think it's unrelated (should not cause the issue number mismatch and shouldn't have it created).

I’ve run into the 500 error before when creating issues one after the other but it was around the time Codeberg was experiencing some other downtime so I attributed it to that.

Will see if I can reliably reproduce. It did initially feel like a rate limit to me too.

(If that’s the case, the rate limit for creating new issues should allow for issues to be created one after another. It’s something that’s commonly done.)

Should I open a separate issue for rate limits being presented as 500 errors or is that being tracked somewhere already? (I can’t find a public issue on it.)

Saw the same issue today when creating issues. Creating an issue returned a 500 server error. Hitting "back" and trying again eventually succeeded on average on the 7th attempt. My colleague had the same issue when she tried.

Unlikely relevant, but all issues had only a subject and no description (these were just placeholders for a kanban).

Hmm, if you're creating placeholder issues one after another, it's indeed likely that you have triggered the rate limit ...

It's very likely that this is the rate limit. I'll try to push a dirty patch.

#425 tracks a proper solution, contributions welcome.

Regarding the issue numbers being out of sync, I still don't understand this.

Regarding the issue numbers being out of sync, I still don't understand this.

Gitea updates the "highest" index in the database, but doesn't revert this update if an error has occured. It seems like this needs to be an atomic operation to avoid out-of-sync, but there is no trival way to do this revert... (it might be via some SQL magic).

Opened a pull request upstream to fix the skipped issue numbers: https://github.com/go-gitea/gitea/pull/21362

@fnetX @Gusted Thanks folks :)

Codeberg/gitea@c2c42bc741 rate limit patch, awaiting approval and deployment. Only a workaround, but will relax the issue a little.

This will be fixed once Gitea 1.18 is released, which can take a while. Will leave it open for now and close it when Gitea 1.18 will be deployed on Codeberg.

Hi @rachelgomez123,

Thank you for informative comment, but the 500 error was causing a bug which is OP's issue.

v1.18 has been deployed. Feel free to re-open if this issue persists.

Hi @rachelgomez123,

Thank you for informative comment, but the 500 error was causing a bug which is OP's issue.

A bit late to the party, but just wanted to point out that the comment you answered to is definitely generated by an LLM, like ChatGPT. The Internet is doomed 🥲