GC task may crash if it encounters an invalid repository

[mpeter50]

Description

Months ago I had a few migrations that failed for some reason.
I don't mean the follow up syncs, but the initial sync.

A few days ago I started using the garbage collect task to regain some storage space, and I've found these repositories by them stopping the whole GC task.
This means when it gets to one of these repositories, it will stop and won't continue with the remaining ones.

Here is a log excerpt I've saved for reference, from when I've encountered this issue:

2022/10/25 20:49:41 .../repository/check.go:84:func1() [E] [63582888-2] Repository garbage collection failed for &{332 5 Migrations <nil> git_access git_access   4 https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/git_access main 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 true true false false <nil> 1 map[] map[] [] <nil> false 0 <nil> false 0 0 <nil> <nil> false false [] default  1647821608 1647821608}. Stdout:
    Error: exit status 128 - fatal: not a git repository (or any parent up to mount point /var/lib)
    Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
     - fatal: not a git repository (or any parent up to mount point /var/lib)
    Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

On taking a closer look, these repositories had a size of 0 bytes according to the repo list on the management interface (gitea.lan/admin/repos), and their directories were ... not empty, but incomplete, like one of them only had the hooks directory, and possibly only part of that even.

I've deleted these repositories since then, and have re-migrated them. GC now does not crash at them.
On that, I think I had difficulties in doing that, as (if I remember correctly) it didn't work through the page with the delete button that is shown when I browse to an invalid repository, but it did work from the above mentioned repo list on the management interface.
Unfortunately I don't have logs about this. I really should set up some central log collection service..

Gitea Version

v1.17.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.36.2

Operating System

Raspbian

How are you running Gitea?

Gitea runs in a Docker container, which was self-built from this repository according to the Docker.rootless Dockerfile.

Database

MySQL

[strk]

I have a similar problem, that is GC task stops on first error. I would think that GC task should continue to next repository rather than stopping. If you see a good use case for stopping the whole thing maybe it could be a configuration setting, but I personally don't see a good reason to stop on first error.

[delvh]

The problem most likely comes from the

for i,v := range <something> {
  if err := function(v); err != nil {
    return err
  }
}

pattern which is used everywhere in Gitea.
I do agree that it probably makes the most sense to ignore an error in this case.

[zeripath]

So the majority of the cron tasks don't propagate errors in this way. I'm not sure why this function was different.