Repositories are broken after unsuccessful clone/mirror creation

[cookiengineer]

• 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.

[pgaskin]

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.

[cookiengineer]

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.

[stale]

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.

[LER0ever]

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.

[zeripath]

I think this would be fixed by #5949

[stale]

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.

[6543]

@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]

I think #6200 do its job now ...