1.11.rc1 - Stuck on checking merge conflicts #4616

New Issue

GiteaMirror · 2025-11-02T05:56:20-06:00

GiteaMirror commented

2025-11-02 05:56:20 -06:00

Originally created by @marcsiq on GitHub (Jan 9, 2020).

Gitea version (or commit ref): 1.11.rc1
Git version:
Operating system: ubuntu
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I didn't know where to post this one, but I did update my gitea to 1.11-rc1 and since then my PRs get stucked in "Checking for merge conflicts, try again in a few moments" after merging in the main branch. I did roll back to 1.10.2 and it seems to work well on that one.

Originally created by @marcsiq on GitHub (Jan 9, 2020). - Gitea version (or commit ref): 1.11.rc1 - Git version: - Operating system: ubuntu - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: ## Description I didn't know where to post this one, but I did update my gitea to 1.11-rc1 and since then my PRs get stucked in "Checking for merge conflicts, try again in a few moments" after merging in the main branch. I did roll back to 1.10.2 and it seems to work well on that one.

GiteaMirror added the issue/needs-feedback type/bug labels 2025-11-02 05:56:20 -06:00

GiteaMirror closed this issue

2025-11-02 05:56:20 -06:00

GiteaMirror commented

2025-11-02 05:56:21 -06:00

@zeripath commented on GitHub (Jan 9, 2020):

@Marcsiq2 rolling back to 1.10.2 doesn't necessary mean that there was a problem on 1.11 - depending on how you rolled back. The worklist could have just taken that long to work through.

We need some log information to work out what is going wrong - if anything.

There were three major changes to the PR checking:

#9282, #9302 and #9501

#9282 might be the cause of your apparent problem as one of the more hidden changes here was to remove a bug whereby PRs would only ever be checked once.

That means that there's potentially lots more PR checking to do - although the queue is uniqued by PRID - possibly we're doing too much for example if the status check fails then the status will remain in checking.

We need logs. Log trace would have told us what the pull request tester was doing here.

For future reference this configuration should give us TRACE level logs for the pull service:

[log]
MODE=...,traceconsole ; Add the traceconsole logger to your current log modes
...

[log.traceconsole]
MODE=console
LEVEL=trace
EXPRESSION=services/pull

@zeripath commented on GitHub (Jan 9, 2020): @Marcsiq2 rolling back to 1.10.2 doesn't necessary mean that there was a problem on 1.11 - depending on how you rolled back. The worklist could have just taken that long to work through. We need some log information to work out what is going wrong - if anything. There were three major changes to the PR checking: #9282, #9302 and #9501 #9282 might be the cause of your apparent problem as one of the more hidden changes here was to remove a bug whereby PRs would only ever be checked once. That means that there's potentially lots more PR checking to do - although the queue is uniqued by PRID - possibly we're doing too much for example if the status check fails then the status will remain in checking. We need logs. Log trace would have told us what the pull request tester was doing here. For future reference this configuration should give us TRACE level logs for the pull service: ``` [log] MODE=...,traceconsole ; Add the traceconsole logger to your current log modes ... [log.traceconsole] MODE=console LEVEL=trace EXPRESSION=services/pull ```

GiteaMirror commented

2025-11-02 05:56:21 -06:00

@marcsiq commented on GitHub (Jan 10, 2020):

Thank you very much for your detailed help! I'll try that.

@marcsiq commented on GitHub (Jan 10, 2020): Thank you very much for your detailed help! I'll try that.

GiteaMirror commented

2025-11-02 05:56:21 -06:00

@zeripath commented on GitHub (Jan 15, 2020):

The console log is emitted on stdout. You can change the mode to file and set a FILE_NAME if you can't use the console.

On 1.10 the EXPRESSION should be models/pull

If you're getting the problem on 1.10 it is likely that you're facing the issue that there is just one worker running the pull request task and it's just busy.

@zeripath commented on GitHub (Jan 15, 2020): The console log is emitted on stdout. You can change the mode to file and set a FILE_NAME if you can't use the console. On 1.10 the EXPRESSION should be models/pull If you're getting the problem on 1.10 it is likely that you're facing the issue that there is just one worker running the pull request task and it's just busy.

GiteaMirror commented

2025-11-02 05:56:21 -06:00

@marcsiq commented on GitHub (Jan 15, 2020):

giteapulls.txt

Find there logs for both 1.10 and 1.11rc1

1.10 worked fine after a restart, while 1.11 is stuck in "checking merge conflict" and nothing else appears on the log.

@marcsiq commented on GitHub (Jan 15, 2020): [giteapulls.txt](https://github.com/go-gitea/gitea/files/4064220/giteapulls.txt) Find there logs for both 1.10 and 1.11rc1 1.10 worked fine after a restart, while 1.11 is stuck in "checking merge conflict" and nothing else appears on the log.

GiteaMirror commented

2025-11-02 05:56:22 -06:00

@marcsiq commented on GitHub (Jan 15, 2020):

giteapulls2.txt

And all this appears and the "checking..." disappears after restarting gitea.

@marcsiq commented on GitHub (Jan 15, 2020): [giteapulls2.txt](https://github.com/go-gitea/gitea/files/4064245/giteapulls2.txt) And all this appears and the "checking..." disappears after restarting gitea.

GiteaMirror commented

2025-11-02 05:56:22 -06:00

@zeripath commented on GitHub (Jan 15, 2020):

I think I've found the cause.

@zeripath commented on GitHub (Jan 15, 2020): I think I've found the cause.

GiteaMirror referenced this issue

2025-11-02 13:21:13 -06:00

[PR #4616] [MERGED] Fix integer constant overflows in tests #17433

Sign in to join this conversation.