Merge conflict checking in progress. Try again in a few minutes

[stu1811]

Description

For the past several version we've run into many PRs that get stuck "Merge conflict checking in progress. Try again in a few minutes". The only work around I've found is to close the PR and open a new one with the same branch. Is there a way to force it to try again?

Gitea Version

1.16.8

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.36.0

Operating System

RHEL 7

How are you running Gitea?

Self hosted behind an apache proxy. I download the amd64 linux binary from the releases page. Binary is started by service at boot.

Database

MySQL

[silentcodeg]

Do you remember at which version of Gitea the problem started to show? That would help narrow down the cause.

[stu1811]

I want to say sometime in the 1.15.X series but it's worse in the past few 1.16.X. Side note I tried updating our git from 2.24.1 to 2.36.0 and it didn't help.

[silentcodeg]

Is there a way for you to reproduce the problem and capture the gitea logs when you do? Or does it happen randomly?

[stu1811]

Which logging should I enable? The current logs aren't very helpful.

[Log]
MODE = file
LEVEL = error
ROUTER_LOG_LEVEL = error

[Server]
DISABLE_ROUTER_LOG = true

[Database]
LOG_SQL = false

Edit: It seems to happen after our main branch is updated. Normally the Update Branch button would be available at this point.
Edit 2: Not sure if it matters but we're using LFS.

[stu1811]

The server is on separate network so I'm manually copying things over.

..dules/git/command.go:146:RunWithContent() [D] /PATH/TO/REPO.git: /usr/bin/git -c credential.helper= -c protocol.version=2 -c uploadpack.allowfilter=true -c uploadpack.allowAnySHA1Want=true -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean=merge-base --refs/heads/main refs/pull/1654/head
..dules/git/command.go:246:RunInDirTimeutEnv() [T] Stdout: <SHA>

[silentcodeg]

This is unfortunately too little information to figure out the cause of the problem. If someone could take a look at the full logs and run some tests with the live instance I'm pretty sure there is a simple explanation.

[99rgosse]

Hello
We ran into the same issue lately, and I think this is linked to (the zombie processes here)[https://github.com//issues/19077] with docker

All those 5 zombie processes are git child of Gitea, running since 22 days for the older ones. (I am still with v1.16.5 under docker & PGsql)

Here is what you get when you restart the container :

I will try to check this with a test instance

[silentcodeg]

This indeed is an issue that seems to be eluding everyone for years. A few bug fixes were applied in this area but there never was a proper bug report on the matter and the root cause is still here, evidently.

Yet, there is a simple way to figure it out if someone was able to get access to a live instance where it happens and the corresponding logs. In your case @99rgosse, the next time it happens, would you be able to investigate further? Looking at the logs from when the zombie git process was launched, trying to figure out which zombie process relates to which operation in Gitea, trying to correlate which task is pending for a long time and why etc. It is tedious but it will lead to a bug report that will be a solid basis for a definitive bug fix.

[stu1811]

@silentcodeg I'm not sure if this is related or a separate issue. If I a edit a file from the gitea website, create a PR, and then make another edit to the same file on the branch, I get "This pull request is broken due to missing fork information." I reproduced it on the demo site.
https://try.gitea.io/developers/foobar/pulls/6

[silentcodeg]

@zeripath just posted a comment here:

#19077 (comment)

that brings some clarity on this topic. In a nutshell, with 1.17 a significant amount of code was modified to:

• prevent that kind of problem
• facilitate the diagnostic of that kind of problem from the admin panel

[silentcodeg]

@silentcodeg I'm not sure if this is related or a separate issue. If I a edit a file from the gitea website, create a PR, and then make another edit to the same file on the branch, I get "This pull request is broken due to missing fork information." I reproduced it on the demo site. https://try.gitea.io/developers/foobar/pulls/6

This is unrelated and would be worth a separate bug report: the reproducer your provide will allow for a quick fix 👍

[lunny]

Hello We ran into the same issue lately, and I think this is linked to (the zombie processes here)[https://github.com//issues/19077] with docker

All those 5 zombie processes are git child of Gitea, running since 22 days for the older ones. (I am still with v1.16.5 under docker & PGsql)

Here is what you get when you restart the container :

I will try to check this with a test instance

Please upgrade to v1.16.8

[99rgosse]

Please upgrade to v1.16.8

I will :)
I did not have time to try yet the upgrade on my test server... I'm always cautious !

[stu1811]

@zeripath just posted a comment here:

#19077 (comment)

that brings some clarity on this topic. In a nutshell, with 1.17 a significant amount of code was modified to:

• prevent that kind of problem
• facilitate the diagnostic of that kind of problem from the admin panel

I build 1.17 dev and my PR that was previously stuck is no longer stuck 🥳

EDIT: There is one error in the log.
patch_unmerged.go:131:unmergedFIles() [E] Unable to run ls-files -u -z! Error: git ls-files -u -z: signal: interrupt