mirror of
https://github.com/go-gitea/gitea.git
synced 2026-03-11 17:46:29 -05:00
Pull requests stuck in "Merge conflict checking is in progress. Try again in few moments" #10145
Open
opened 2025-11-02 08:59:21 -06:00 by GiteaMirror
·
32 comments
No Branch/Tag Specified
main
release/v1.25
release/v1.24
release/v1.23
release/v1.22
release/v1.21
release/v1.20
release/v1.19
release/v1.18
release/v1.17
release/v1.16
release/v1.15
release/v1.14
release/v1.13
release/v1.12
release/v1.11
release/v1.10
release/v1.9
release/v1.8
v1.25.3
v1.25.2
v1.25.1
v1.25.0
v1.24.7
v1.25.0-rc0
v1.26.0-dev
v1.24.6
v1.24.5
v1.24.4
v1.24.3
v1.24.2
v1.24.1
v1.24.0
v1.23.8
v1.24.0-rc0
v1.25.0-dev
v1.23.7
v1.23.6
v1.23.5
v1.23.4
v1.23.3
v1.23.2
v1.23.1
v1.23.0
v1.23.0-rc0
v1.24.0-dev
v1.22.6
v1.22.5
v1.22.4
v1.22.3
v1.22.2
v1.22.1
v1.22.0
v1.23.0-dev
v1.22.0-rc1
v1.21.11
v1.22.0-rc0
v1.21.10
v1.21.9
v1.21.8
v1.21.7
v1.21.6
v1.21.5
v1.21.4
v1.21.3
v1.21.2
v1.20.6
v1.21.1
v1.21.0
v1.21.0-rc2
v1.21.0-rc1
v1.20.5
v1.22.0-dev
v1.21.0-rc0
v1.20.4
v1.20.3
v1.20.2
v1.20.1
v1.20.0
v1.19.4
v1.21.0-dev
v1.20.0-rc2
v1.20.0-rc1
v1.20.0-rc0
v1.19.3
v1.19.2
v1.19.1
v1.19.0
v1.19.0-rc1
v1.20.0-dev
v1.19.0-rc0
v1.18.5
v1.18.4
v1.18.3
v1.18.2
v1.18.1
v1.18.0
v1.17.4
v1.18.0-rc1
v1.19.0-dev
v1.18.0-rc0
v1.17.3
v1.17.2
v1.17.1
v1.17.0
v1.17.0-rc2
v1.16.9
v1.17.0-rc1
v1.18.0-dev
v1.16.8
v1.16.7
v1.16.6
v1.16.5
v1.16.4
v1.16.3
v1.16.2
v1.16.1
v1.16.0
v1.15.11
v1.17.0-dev
v1.16.0-rc1
v1.15.10
v1.15.9
v1.15.8
v1.15.7
v1.15.6
v1.15.5
v1.15.4
v1.15.3
v1.15.2
v1.15.1
v1.14.7
v1.15.0
v1.15.0-rc3
v1.14.6
v1.15.0-rc2
v1.14.5
v1.16.0-dev
v1.15.0-rc1
v1.14.4
v1.14.3
v1.14.2
v1.14.1
v1.14.0
v1.13.7
v1.14.0-rc2
v1.13.6
v1.13.5
v1.14.0-rc1
v1.15.0-dev
v1.13.4
v1.13.3
v1.13.2
v1.13.1
v1.13.0
v1.12.6
v1.13.0-rc2
v1.14.0-dev
v1.13.0-rc1
v1.12.5
v1.12.4
v1.12.3
v1.12.2
v1.12.1
v1.11.8
v1.12.0
v1.11.7
v1.12.0-rc2
v1.11.6
v1.12.0-rc1
v1.13.0-dev
v1.11.5
v1.11.4
v1.11.3
v1.10.6
v1.12.0-dev
v1.11.2
v1.10.5
v1.11.1
v1.10.4
v1.11.0
v1.11.0-rc2
v1.10.3
v1.11.0-rc1
v1.10.2
v1.10.1
v1.10.0
v1.9.6
v1.9.5
v1.10.0-rc2
v1.11.0-dev
v1.10.0-rc1
v1.9.4
v1.9.3
v1.9.2
v1.9.1
v1.9.0
v1.9.0-rc2
v1.10.0-dev
v1.9.0-rc1
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.8.0-rc3
v1.7.6
v1.8.0-rc2
v1.7.5
v1.8.0-rc1
v1.9.0-dev
v1.7.4
v1.7.3
v1.7.2
v1.7.1
v1.7.0
v1.7.0-rc3
v1.6.4
v1.7.0-rc2
v1.6.3
v1.7.0-rc1
v1.7.0-dev
v1.6.2
v1.6.1
v1.6.0
v1.6.0-rc2
v1.5.3
v1.6.0-rc1
v1.6.0-dev
v1.5.2
v1.5.1
v1.5.0
v1.5.0-rc2
v1.5.0-rc1
v1.5.0-dev
v1.4.3
v1.4.2
v1.4.1
v1.4.0
v1.4.0-rc3
v1.4.0-rc2
v1.3.3
v1.4.0-rc1
v1.3.2
v1.3.1
v1.3.0
v1.3.0-rc2
v1.3.0-rc1
v1.2.3
v1.2.2
v1.2.1
v1.2.0
v1.2.0-rc3
v1.2.0-rc2
v1.1.4
v1.2.0-rc1
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.2
v1.0.1
v1.0.0
v0.9.99
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
Mirrored from GitHub Pull Request
Milestone
No items
No Milestone
Projects
Clear projects
No project
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/gitea#10145
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tautf on GitHub (Jan 23, 2023).
Description
After the update to 1.18.2 all our pull requests are stuck with above error message. I did restart the server multiple times already, we cannot get out of this view.
This was not happening with 1.17.4 and 1.18.0.
I upgraded from 1.18.0 to 1.18.2 and skipped 1.18.1, could that cause the issue?
Problem got worse with 1.18.0 that it became slower but it at least resolved after 10-15 minutes. Now we are stuck for multiple hours.
I am using the gogit variant but it looks like the windows side git is used or am i wrong?
Not sure if the logs are related to it but thats the only errors i could find. I have disabled my anti-virus but the issue still persists.
Gitea Version
1.18.2
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
Screenshots
No response
Git Version
2.39.1
Operating System
Windows Server 2019
How are you running Gitea?
Windows Service
Database
PostgreSQL
@tautf commented on GitHub (Jan 23, 2023):
Also some PR's are still stuck in
Resolve conflictsas there were some which have been resolved.Looks like it doesn't retrigger the check. Is there a way to trigger the scan manually?
Current situation is pretty ugly because we cannot properly update/merge our branches via Gitea.
@a1012112796 commented on GitHub (Jan 24, 2023):
have you seen the

Stderrmessgae? it maybe at the next line after this line.@tautf commented on GitHub (Jan 24, 2023):
Unfortunately not. This is the block that is always printed:
I also found out that the problem does not happen initially on new pull requests. Only as soon as they get updated.
Asking for assistance, as mentioned it's hard to work with Gitea like this.
@tautf commented on GitHub (Jan 24, 2023):
If i click on a affected pull request, the following block is the only thing that is printed:
@tautf commented on GitHub (Jan 24, 2023):
I noticed also, the amount of given approvals differs in the /pulls view to the approvals inside the /pulls/:id view. And this PR is in status ''Merge conflict checking is in progress. Try again in few moments."
See:



Edit: Extra info on this, the affected user (the one whos review is not displayed) is always the same.
@tautf commented on GitHub (Jan 24, 2023):
Found the following in the logs, may cause this issue?
@tautf commented on GitHub (Jan 24, 2023):
Looks like its a duplicate of https://github.com/go-gitea/gitea/issues/17204.
@tautf commented on GitHub (Jan 24, 2023):
Closing the PR and reopening it, seems to fix the issue after i reverted git Version to 2.29.1, the version we have been on before we updated to 1.18.2
@zeripath commented on GitHub (Jan 24, 2023):
@tauf I suspect that there is something wrong with that repository on the filesystem. Have you ran git gc, git fsck and git repack on that repo?
It would also be helpful to check if there is a process stuck in conflict checking. On the admin pages there is a process stacktrace available off a link on the management pages. You can also get it from
gitea manager processes --stacktraces@tautf commented on GitHub (Jan 25, 2023):
@zeripath Can you assist me with the git commands you mentioned? I'm not that familiar with git.
I found stacktraces but there is no link to download them, can you tell me where exactly?
Also this is still an issue:
https://github.com/go-gitea/gitea/issues/22578#issuecomment-1401496068
@tautf commented on GitHub (Jan 25, 2023):
After some time it worked with new pull requests, now we have the same situation again. The pull requests are stuck in the same state. May i ask somebody to assist me with this?
@tautf commented on GitHub (Jan 25, 2023):
@zeripath like this?
@tautf commented on GitHub (Jan 25, 2023):
More info from gitea admin pages:


Muted logs to warn, that what i see all day:
@zeripath commented on GitHub (Jan 26, 2023):
@tautf you're not providing us with anything that can help us to get to the bottom of the problem.
STACKTRACES
I've asked for the stacktraces. Could you please give me the stacktraces? These can be obtained extremely easily:
GIT COMMIT
You say you see:
Have you been able to see if there is a git process already running in the repository? Are there hanging processes in your process manager? Somewhat annoyingly you've cut off the first line of that message so I cannot determine which line this relates to. Which piece of code emits that?
LOGS
Setting your logs to WARN is not going to help us to debug your problem. It would be also be helpful to adjust your logging:
Your logs above in https://github.com/go-gitea/gitea/issues/22578#issuecomment-1401470526 are not related in any way to the PR checking process so are unhelpful.
The logs in https://github.com/go-gitea/gitea/issues/22578#issuecomment-1403679983 are also unhelpful. Without telling me the line that emits this: https://github.com/go-gitea/gitea/issues/22578#issuecomment-1401529165 it is also unhelpful.
I need the logs from when the PR starts to be checked. So right from the push that sets off the checker, for a good while afterwards until you're sure that the PR has been checked and failed to be checked.
APP.INI
It would also be helpful to see your app.ini. I need to know whether you have some weird queue set up that is breaking the PR checker.
SIZE
I need to know around how many PRs you have on your system - it may be that you've just got so many that PR checker takes too long.
@zeripath commented on GitHub (Jan 26, 2023):
as an aside I've just looked at the code for
checkIfPRContentChangedand it really needs to be improved. I can see why you might be getting theanother git processmessages - and this might be the reason why you're getting conflict checking problems - but I still need the above logs.@tautf commented on GitHub (Jan 27, 2023):
@zeripath thanks for your response. Sorry that i was providing unhelpful information.
Requested info:
Stacktraces:
`./gitea.exe manager processes --stacktraces`
Logs
https://pastebin.com/kbCcFpMn
app.ini
Size
Currently there is 13 PR's open. When the issue occured it were about 20. Never have more. Issues around 80-100 on average.
@zeripath commented on GitHub (Jan 27, 2023):
Heya!
Thanks for the much more extensive logs.
Stacktraces
Looking at the stacktraces - your request to the stacktrace started at 2023-01-27 08:12:24 and at 2023-01-27 08:12:23 PR[653] = PR number #998 in Repo[24] started being checked. So that doesn't provide evidence of hanging PR checks. You'd need to run stacktraces again in a bit to see if the same PR was hanging somewhere.
When did you run stacktraces - it appears early as compared to your logs? Stacktraces is instantaneous - it tells me what is happening at the point of running it - it's helpful to get the stacktrace when you think the problem is occurring - although it is also helpful to get a baseline.
Could you tell me the ID and/or Index number of the/a PR that is blocked? Is #998 in Repo[24]/PR[653] the blocked PR?
App.ini
I see:
This was related to a previous bug which should have been fixed. I don't think this could be causing problems but it's not really necessary anymore.
Logs
I need to know which PR is blocked. There is a lot of PR checking going on there. (I do think our logging here is a little poor as despite my attempts to improve things we still don't have enough context within the trace logging to clearly identify immediately which PR each trace is going to and there doesn't appear to be clear tracing as to when PRs finish being checked.)
For example, working backwards from your logs:
2782c14396/services/pull/patch.go (L98-L101)merge-base- but without a terminal stacktraces I can't see what happened to that process.Now the PRs that stop after merge-base I think that's because the pr.HeadCommitID is equal to the MergeBase and they're probably ancestors.
However, looking at your logs I see you've tried to view heat-coat/app#1079 head kd-chore-fixed-css-and-html-for-order-item-creation but I don't see any checking for that PR. I can't tell from your logs if that's just due to timing
What I do see is that there are 24 PRs in the patch checking queue but your logs stop at 12 PRs - so maybe you're just checking too early? But I see that in the monitor screenshot you sent above there were none waiting.
OK thanks for logs but I need more.
It probably is worth running:
and then send us the logs and the stacktraces. If
flush-queueshangs then send us the logs too.We also need to improve our logging considerably too. I will look at that.
@tdesveaux commented on GitHub (Feb 24, 2023):
Hi!
We encountered the same issue on our Gitea instance.
We had a 500 error when opening a
/compare/url.When I looked at the log, I saw this error:
So I added some dashes to commands:
80e504c2e7Then I was still left with an error that I managed to track to this code: https://github.com/go-gitea/gitea/blob/main/modules/git/repo_compare.go#L42
logging the
errgave me the same information as in this issue regarding thecommit-graph-chain.lockSo I simply added a
--no-write-commit-graphas you can see here:07b38b7488I can rebase these commits (or only the
--no-write-commit-graphone) against main and open a PR if this approach is acceptable.However, the fact the function somewhat ignores the fetch error and goes along maybe should be addressed as well?
@Sebazzz commented on GitHub (Mar 20, 2023):
Also running into this issue (Windows Server), with no further information:
Not having this issue on the go-git version, apparently.
@wxiaoguang commented on GitHub (Mar 21, 2023):
My personal opinion (does not represent the opinion of the Gitea or maintainers):
I think it's good enough (sorry that I missed your message about "open a PR if this approach is acceptable"), so I closed my duplicate one.
I have some questions about it:I guess there is a concurrency problem
@tdesveaux commented on GitHub (Mar 21, 2023):
IIRC, this is in the 'true' repository (didn't push my investigation into if a tmp repository would be better suited) but it's a tmp remote that is added then removed just after. So I guess it could impact performances for git commands that would run while this remote is present but should only impact a subset of commands that use the commit graph?
The lock file seem to be unique for commit-graph operations
objects/info/commit-graphs/commit-graph-chain.lockso I would say other locks still apply.IIRC, this will make git update a commit-graph in memory as normal but will just prevent writing it to disk for caching.
@wxiaoguang commented on GitHub (Mar 22, 2023):
Agree, that's also an unclear part in my mind. According to "the commit-graph file format is faster to parse than decompressing commit files and parsing them to find their parents and root trees.", so I guess the following "merge-base" and "log" commands may benefit from it, but I do not know how much benefit it brings, maybe it differs between big and small repositories. So I have no idea TBH ....
Personally I would agree with that adding "--no-write-commit-graph" is fine for most cases.
From another side, I think maybe Gitea has a design flaw (bug) in its conflict checking code. If there are concurrent git operations, then the "conflict checking" should retry instead of getting stuck if the competition for the lock fails.
If the lock competition could be handled correctly, then no need to worry about the commit-graph lock?
@brechtvl commented on GitHub (Jul 19, 2023):
We ran into the same
commit-graph-chain.lockerror on projects.blender.org. In comparing branches before creating a pull request, rather than pull request conflict checking. A number of forked repositories ended up withcommit-graph-chain.lock.The
--no-write-commit-graphworkaround solved that for us, but the root cause is still unclear. I wonder if the lock file is created because there are operations being done on the original repository, or if the temporary repositories for operations like conflict checking are perhaps not as isolated as expected.Perhaps a Git crash or kill after a timeout could cause this too.
@lunny commented on GitHub (Jul 19, 2023):
We can have a cron job to cleanup the
commit-graph-chain.lockfiles at the backend. It cannot be avoid at the moment.@liuyangovo commented on GitHub (Mar 29, 2024):
@zeripath
Background: We have a 2.3GB repository that cannot be split due to historical reasons. Currently, we are submitting a merge and conflict checking will take 10-20 minutes
Observation:
Problem:
Here are the stack logs
@liuyangovo commented on GitHub (Jun 12, 2024):
Each merge merged into the main branch, all open status pull request will perform a merge conflict checking,If you have a very old pull request, Please mark it as WIP, reduce the number of conflict queues and accelerate the speed of conflict checking
@wienans commented on GitHub (Oct 29, 2024):
@lunny is there anything regarding this already implemented in the latest versions? Or a other suggested Workaround?
@lunny commented on GitHub (Oct 30, 2024):
As a workaround, just find all
commit-graph-chain.lockfiles and delete them.@bsofiato commented on GitHub (Nov 8, 2024):
@lunny Would you like me to try to implement this cron job solution ? If it is ok with you guys I would love to
@lunny commented on GitHub (Nov 8, 2024):
Maybe we can have two improvements. One is trying to delete the lock file once we got
Killedfrom git command sub process immediately. Another is having a cron task to clean all lock files. ref https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2099/diffs . And yes, I think it's necessary to integration the ability to clean up them.@bsofiato commented on GitHub (Nov 8, 2024):
Makes sense. I'll work on that :) I think by next week I should have both PRs done.
@lunny commented on GitHub (Aug 23, 2025):
I think we should first add a manual task to clean up these lock files.