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

KOLANICH commented 2023年10月02日 19:05:41 +02: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.

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

### 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

fnetX commented 2023年11月16日 22:43:41 +01:00

I freed your repos, but the problem still stands.

I freed your repos, but the problem still stands.

KOLANICH commented 2023年11月21日 14:05:25 +01:00

Thank you!

Thank you!

Metadustrie commented 2024年06月09日 17:40:32 +02:00

Hello,
I had the same problem today with the pages repo.
How can I solve the problem ?

Hello, I had the same problem today with the ```pages``` repo. How can I solve the problem ?

fnetX commented 2024年06月09日 23:56:40 +02:00

@Metadustrie if you visit your user settings > repositories, you can check for "unadopted" repositories that exist on disk but not in the software.

If your repo still exists in the software but is not working (corrupted), you can often append /settings to the URL and delete it from there.

@Metadustrie if you visit your user settings > repositories, you can check for "unadopted" repositories that exist on disk but not in the software. If your repo still exists in the software but is not working (corrupted), you can often append /settings to the URL and delete it from there.

scgummy commented 2025年08月04日 01:29:03 +02:00

@fnetX Hi, I've hit the same issue during my migration for openh264-rs. I couldn't see any leftover in my "Settings > Repositories", could you please help? Thanks!

@fnetX Hi, I've hit the same issue during my migration for `openh264-rs`. I couldn't see any leftover in my "Settings > Repositories", could you please help? Thanks!

fnetX commented 2025年08月04日 11:13:48 +02:00

I have deleted the repo now.

I have deleted the repo now.

0x7E commented 2025年08月20日 14:34:21 +02:00

@fnetX Hello, I got a similar issue while trying to create a nd repo, the creation failed but it now says "Files already exist for this repository". It's not listed anywhere either

@fnetX Hello, I got a similar issue while trying to create a `nd` repo, the creation failed but it now says "Files already exist for this repository". It's not listed anywhere either

fnetX commented 2025年08月21日 14:19:02 +02:00

@0x7E I deleted the files for you as well.

@0x7E I deleted the files for you as well.

Gusted commented 2025年08月26日 21:09:31 +02:00

Please create a new issue if this happens, thank you.

Please create a new issue if this happens, thank you.