gitea: Migrations permanently stuck if gitea is restarted during the migration
- Gitea version (or commit ref): 1.12.5
- Git version: 2.20.1
- Operating system: Debian 10, used the “getting started on linux” instructions from the main site
- Database (use
[x]):- PostgreSQL
- MySQL
- MSSQL
- SQLite
- Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No, cannot restart try.gitea.io manually
- Log gist:
Description
https://github.com/go-gitea/gitea/issues/8812#issuecomment-549700212
Same as mentioned there. Forcefully restarting gitea while a migration is happening will cause any unfinished/pending migrations to hang indefinitely. Manually running the cron tasks in the administration panel does nothing.
I just spent about 5 hours scouring the web for clone links for a bunch of dependencies we need to mirror, I would really prefer not to have to do that again.
Screenshots

About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 19 (11 by maintainers)
I’m not being aggressive, I just seem to have a different viewpoint than you about software robustness.
A fault tolerant web service has the property that, in the event of a failure of any kind, it is able to error-correct and resume operations without manual intervention.
There could be a new cron-job; pseudo-code:
I don’t see how what I’m saying is “aggressive”, I apologize if you’ve perceived it that way. However, I’m not going to pretend the current behavior is correct or that it’s not a bug. If you’re not interested in fixing it, that’s fine - I can find another solution, it’s not a problem. However, I wanted to let you know that this is indeed an issue and that I simply wanted to express that the two responses - “why are you restarting?” and “It’s SQLite’s problem” - don’t make much sense to me as they do not address the fault tolerance point.
If SQLite makes it easy for gitea to fail, then gitea should probably have error-correcting logic to correct any errors SQLite might cause.
That’s all.
I merely insinuated that a web service would be more robust if it could survive unexpected shutdowns. Gitea being force-killed put it into a corrupted state that cannot be resumed or error-corrected, which is a dist-sys problem.
I’m a dist-sys architect; asking me “why are you restarting [a web service]” is like asking me “why did you make your server’s power go out during a thunderstorm?”. I didn’t want that to happen, but it happens. A robust service would be fault tolerant of that.
With a single instance running, I highly doubt this is purely SQLite’s fault (there are not multiple actors here). Perhaps I’m missing implementation details, but it seems like maybe something could be improved to increase the robustness against failures.
That’s all I was implying. 🙂 I wasn’t trying to put anyone down, but I didn’t see how the question fit the bug report at all.