gitea: handleCreateError()] [E] CreatePost: database table is locked: repository'

The pattern used at https://github.com/go-gitea/gitea/blob/master/models/repo.go#L2000 is probably related.

See the pattern at the beginning of several related functions:

	if taskStatusTable.IsRunning(gitFsck) {
		return
	}
	taskStatusTable.Start(gitFsck)
	defer taskStatusTable.Stop(gitFsck)

It looks like the intention is to emulate some kind of mutex lock, but the problem is the read and lock is not combined into an atomic operation. They are separated into IsRunning() and Start() respectively. That could be problematic because there is no guarantee that, at the very moment after the call to IsRunning and before Start, another goroutine wouldn’t be launched and calling into the same sequence.

Similar to #1434 and #1372 At least for #1372 it doesn’t have to do with load as I was the only one using the system at that point.

Once the new integration test is merged, we can add certain stress tests for such scenario. I am also thinking about migrate all global maps to syncmap gradually. That makes sense because gitea is a highly concurrent application.