Possible race condition between importing a repo from GitHub and its deletion results in a permanently occupied project name for an inexistent project #1307

New Issue

Open

opened 2023-10-02 17:05:41 +00:00 by KOLANICH · 2 comments

KOLANICH commented

2023-10-02 17:05:41 +00:00

Comment

Sometimes, when a repo is imported from GitHub, importing stalls ethernally. My hypothesis is that Codeberg backend IP address runs out of GitHub API requests quota (60 per hour for an IP, 1000 per hour for an API token) and doesn't process the error properly. Then the solution is to go to settings link and delete the partly-imported repo (it is unusable on that point). And then try again later. Mostly this works, but in a large enough (the minority, but even 1 such case is enough to create problems) fraction of such failed tries the following happens.

The repo got "deleted".
a. https://codeberg.org/<namespace>/<repo name> results in 404
b. https://codeberg.org/<namespace>/<repo name>/settings results in 404
Its name doesn't get freed: any attempt to create such a repo results in an error.
a. trying to import to such name results in a message "The repository name is already used."
b. trying to create it from scratch results in "Files already exist for this repository. Contact the system administrator."

The hypothesis is that a race condition happens and migration process does something after the repo is deleted by user explicitly.

It'd be nice to

investigate the bugs leading to the issue;
fix the bugs;
find ways to detect and clean such lost names.

The temporary workarounds are:

when importing, use a temporary name you will never need
rename the repo into a name you will never need before deleting it

### Comment Sometimes, when a repo is imported from GitHub, importing stalls ethernally. My hypothesis is that Codeberg backend IP address runs out of GitHub API requests quota (60 per hour for an IP, 1000 per hour for an API token) and doesn't process the error properly. Then the solution is to go to settings link and delete the partly-imported repo (it is unusable on that point). And then try again later. Mostly this works, but in a large enough (the minority, but even 1 such case is enough to create problems) fraction of such failed tries the following happens. 1. The repo got "deleted". a. `https://codeberg.org/<namespace>/<repo name>` results in 404 b. `https://codeberg.org/<namespace>/<repo name>/settings` results in 404 2. Its name doesn't get freed: any attempt to create such a repo results in an error. a. trying to import to such name results in a message "The repository name is already used." b. trying to create it from scratch results in "Files already exist for this repository. Contact the system administrator." The hypothesis is that a race condition happens and migration process does something after the repo is deleted by user explicitly. It'd be nice to 1. investigate the bugs leading to the issue; 2. fix the bugs; 3. find ways to detect and clean such lost names. The temporary workarounds are: * when importing, use a temporary name you will never need * rename the repo into a name you will never need before deleting it