Repositories are broken after unsuccessful clone/mirror creation #495

New Issue

GiteaMirror · 2025-11-02T03:25:30-06:00

GiteaMirror commented

2025-11-02 03:25:30 -06:00

Originally created by @cookiengineer on GitHub (Mar 14, 2017).

Git version: 1.1.0
Operating system: Arch Linux (both ARM and amd64)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist: -

Description

When cloning a big repository on a slow (or time-outing) internet connection, the repository will be invalid and show a 500 error if the connection was interrupted or the cloning process was unsuccessful. You have to manually connect to the database on the machine and to remove all entries related to the repository to make it work again (or to retry cloning). This is bad error handling :-/

Expected Behaviour

Cloning process should be asynchronous and schedule it in the background, and not depend on the web interface opened up in the web browser. If clone fails, a message would be nice with an option to quickly delete the broken repository (or to try it again).

Steps to Reproduce

Use gitea on a cable connected machine (for easy reproduction)
Click + and create new repository
Migrate or clone a big repository from the interwebz
While cloning, pull the cable from the machine
Voila, repository is broken with 500 error

Alternative Steps to Reproduce

Disconnect Modem or use a network-wide Proxy with latency (e.g. TOR).

This issue is not dependent on whether giteaserver <> usermachine are connected or not. If git clone fails, repo is broken and browser will not receive any data in its never-ending request.

Originally created by @cookiengineer on GitHub (Mar 14, 2017). - Git version: 1.1.0 - Operating system: Arch Linux (both ARM and amd64) - Database (use `[x]`): - [x] PostgreSQL - [x] MySQL - [x] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: - ## Description When cloning a big repository on a slow (or time-outing) internet connection, the repository will be invalid and show a 500 error if the connection was interrupted or the cloning process was unsuccessful. You have to manually connect to the database on the machine and to remove all entries related to the repository to make it work again (or to retry cloning). This is bad error handling :-/ ## Expected Behaviour Cloning process should be asynchronous and schedule it in the background, and not depend on the web interface opened up in the web browser. If clone fails, a message would be nice with an option to quickly delete the broken repository (or to try it again). ## Steps to Reproduce - Use gitea on a cable connected machine (for easy reproduction) - Click `+` and create new repository - Migrate or clone a _big_ repository from the interwebz - While cloning, pull the cable from the machine - Voila, repository is broken with 500 error ## Alternative Steps to Reproduce Disconnect Modem or use a network-wide Proxy with latency (e.g. TOR). This issue is not dependent on whether giteaserver <> usermachine are connected or not. If git clone fails, repo is broken and browser will not receive any data in its never-ending request.

GiteaMirror added the issue/confirmed type/bug labels 2025-11-02 03:25:30 -06:00

GiteaMirror closed this issue

2025-11-02 03:25:30 -06:00

GiteaMirror commented

2025-11-02 03:25:30 -06:00

@pgaskin commented on GitHub (Mar 14, 2017):

For me, this will happen until the repository is fully cloned. Try waiting a bit longer, or look at the monitoring section of the admin.

@pgaskin commented on GitHub (Mar 14, 2017): For me, this will happen until the repository is fully cloned. Try waiting a bit longer, or look at the monitoring section of the admin.

GiteaMirror commented

2025-11-02 03:25:30 -06:00

@cookiengineer commented on GitHub (Mar 14, 2017):

I can't wait longer than hours. The bug, as described above, will break the repository no matter if your browser is still open or not. It will be just an endless reloading website that never receives any HTML data, nothing more.

The backend side seems to wait until the clone was successfully completed. If anything happens in between, the repo will break and the browser will not receive an error message.

Above instruction were meant for reproduction. Any case in between can happen, from DNS timeout to proxy latency to routing issues (e.g. TOR). In any given case: If the git clone fails, everything is broken and the client-side that initiated the git clone via web interface never receives any answer from the gitea backend. This is not cable-connection-between-user-and-gitea specific.

@cookiengineer commented on GitHub (Mar 14, 2017): I can't wait longer than hours. The bug, as described above, will break the repository no matter if your browser is still open or not. It will be just an endless reloading website that never receives any HTML data, nothing more. The backend side seems to wait until the clone was successfully completed. If anything happens in between, the repo will break and the browser will not receive an error message. Above instruction were meant for reproduction. Any case in between can happen, from DNS timeout to proxy latency to routing issues (e.g. TOR). In any given case: If the git clone fails, everything is broken and the client-side that initiated the git clone via web interface never receives any answer from the gitea backend. This is not cable-connection-between-user-and-gitea specific.

GiteaMirror commented

2025-11-02 03:25:31 -06:00

@stale[bot] commented on GitHub (Feb 16, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 16, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 03:25:31 -06:00

@LER0ever commented on GitHub (Feb 17, 2019):

This issue is still present on Git master today.
Migrating a large repo from Github caused timeout from proxy and visiting that repo just gives 500.

@LER0ever commented on GitHub (Feb 17, 2019): This issue is still present on Git master today. Migrating a large repo from Github caused timeout from proxy and visiting that repo just gives 500.

GiteaMirror commented

2025-11-02 03:25:31 -06:00

@zeripath commented on GitHub (Feb 17, 2019):

I think this would be fixed by #5949

@zeripath commented on GitHub (Feb 17, 2019): I think this would be fixed by #5949

GiteaMirror commented

2025-11-02 03:25:31 -06:00

@stale[bot] commented on GitHub (Apr 18, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Apr 18, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 03:25:31 -06:00

@6543 commented on GitHub (Oct 24, 2019):

@lunny I think we can close this

If you test you get an 404 after reload and if you check our repos the repo is deleted / was not created ...

@6543 commented on GitHub (Oct 24, 2019): @lunny I think we can close this If you test you get an 404 after reload and if you check our repos the repo is deleted / was not created ...

GiteaMirror commented

2025-11-02 03:25:32 -06:00

@6543 commented on GitHub (Oct 24, 2019):

I think #6200 do its job now ...

@6543 commented on GitHub (Oct 24, 2019): I think #6200 do its job now ...

GiteaMirror referenced this issue

2025-11-02 11:45:59 -06:00

[PR #495] [MERGED] Optimization for user.GetRepositoryAccesses to reduce db query times #15412

Sign in to join this conversation.