Cannot change PR target branch (causes 100% CPU) #5557

New Issue

GiteaMirror · 2025-11-02T06:28:51-06:00

GiteaMirror commented

2025-11-02 06:28:51 -06:00

Originally created by @danwilliams on GitHub (Jun 16, 2020).

Gitea version (or commit ref): 1.13.0+dev-199-g80a3745fc
Git version: 2.11.0
Operating system: Debian Stretch (up-to-date)
Database:
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

If I try to change the target ("merge into") branch for an existing PR, it calls POST /project-name/repo-name/pull/{pull-id}/target_branch, but the XHR request never finishes (just says "pending" forever). So the target branch doesn't get updated.

Doing this also causes the gitea process to max out a CPU core. If tried repeatedly, it maxes out another core each time, getting to and maintaining 100% if you try to change the target branch multiple times. This seems to never end (has been observed going on for days). Presumably each attempt uses a thread.

There is nothing listed in Running Processes under the Gitea admin panel.

If I restart Gitea and use it as normal, the CPU doesn't spike. It only happens when I try to change the target branch of a PR.

I have the logging set to Trace, but am not seeing any errors, and also not seeing an UPDATE query being executed against the pull_request table, which is where I'd expect it to update the base_branch column.

So something is going wrong in between the start of the request, and the place in the code where it would run that query.

This has been reproduced on a number of repositories on the same server. Each has had gc etc. run and is clean.

Out of interest this bug has been around for many months - I thought the branch changing was simply broken, and that a fix would be along at some point. In noticing the CPU usage and investigating further today, the full behaviour has become apparent. Gitea is kept up-to-date regularly (every week or two against master).

Originally created by @danwilliams on GitHub (Jun 16, 2020). - Gitea version (or commit ref): 1.13.0+dev-199-g80a3745fc - Git version: 2.11.0 - Operating system: Debian Stretch (up-to-date) - Database: - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: ## Description If I try to change the target ("merge into") branch for an existing PR, it calls `POST /project-name/repo-name/pull/{pull-id}/target_branch`, but the XHR request never finishes (just says "pending" forever). So the target branch doesn't get updated. Doing this also causes the `gitea` process to max out a CPU core. If tried repeatedly, it maxes out another core each time, getting to and maintaining 100% if you try to change the target branch multiple times. This seems to never end (has been observed going on for days). Presumably each attempt uses a thread. There is nothing listed in Running Processes under the Gitea admin panel. If I restart Gitea and use it as normal, the CPU doesn't spike. It only happens when I try to change the target branch of a PR. I have the logging set to `Trace`, but am not seeing any errors, and also not seeing an `UPDATE` query being executed against the `pull_request` table, which is where I'd expect it to update the `base_branch` column. So something is going wrong in between the start of the request, and the place in the code where it would run that query. This has been reproduced on a number of repositories on the same server. Each has had `gc` etc. run and is clean. Out of interest this bug has been around for many months - I thought the branch changing was simply broken, and that a fix would be along at some point. In noticing the CPU usage and investigating further today, the full behaviour has become apparent. Gitea is kept up-to-date regularly (every week or two against master).

GiteaMirror added the issue/stale label 2025-11-02 06:28:51 -06:00

GiteaMirror closed this issue

2025-11-02 06:28:51 -06:00

GiteaMirror commented

2025-11-02 06:28:52 -06:00

@zeripath commented on GitHub (Jun 17, 2020):

This is weird I can't seem to replicate the problem.

Are you able to build Gitea from source code? You could apply the below patch to determine where the sticking point is:

diff --git a/services/pull/pull.go b/services/pull/pull.go
index b94a46639..1aee4b865 100644
--- a/services/pull/pull.go
+++ b/services/pull/pull.go
@@ -156,11 +156,15 @@ func ChangeTargetBranch(pr *models.PullRequest, doer *models.User, targetBranch
        oldBranch := pr.BaseBranch
        pr.BaseBranch = targetBranch
 
+       log.Debug("About to test patch: pr [%d] in %-v", pr.Index, pr.BaseRepo)
+
        // Refresh patch
        if err := TestPatch(pr); err != nil {
                return err
        }
 
+       log.Debug("Done testing patch: pr [%d] in %-v", pr.Index, pr.BaseRepo)
+
        // Update target branch, PR diff and status
        // This is the same as checkAndUpdateStatus in check service, but also updates base_branch
        if pr.Status == models.PullRequestStatusChecking {
@@ -175,9 +179,12 @@ func ChangeTargetBranch(pr *models.PullRequest, doer *models.User, targetBranch
        pr.CommitsAhead = divergence.Ahead
        pr.CommitsBehind = divergence.Behind
 
+       log.Debug("Got divergence: pr [%d] in %-v", pr.Index, pr.BaseRepo)
+
        if err := pr.UpdateColsIfNotMerged("merge_base", "status", "conflicted_files", "base_branch", "c>
                return err
        }
+       log.Debug("UpdatedCols: pr [%d] in %-v", pr.Index, pr.BaseRepo)
 
        // Create comment
        options := &models.CreateCommentOptions{

@zeripath commented on GitHub (Jun 17, 2020): This is weird I can't seem to replicate the problem. Are you able to build Gitea from source code? You could apply the below patch to determine where the sticking point is: ```diff diff --git a/services/pull/pull.go b/services/pull/pull.go index b94a46639..1aee4b865 100644 --- a/services/pull/pull.go +++ b/services/pull/pull.go @@ -156,11 +156,15 @@ func ChangeTargetBranch(pr *models.PullRequest, doer *models.User, targetBranch oldBranch := pr.BaseBranch pr.BaseBranch = targetBranch + log.Debug("About to test patch: pr [%d] in %-v", pr.Index, pr.BaseRepo) + // Refresh patch if err := TestPatch(pr); err != nil { return err } + log.Debug("Done testing patch: pr [%d] in %-v", pr.Index, pr.BaseRepo) + // Update target branch, PR diff and status // This is the same as checkAndUpdateStatus in check service, but also updates base_branch if pr.Status == models.PullRequestStatusChecking { @@ -175,9 +179,12 @@ func ChangeTargetBranch(pr *models.PullRequest, doer *models.User, targetBranch pr.CommitsAhead = divergence.Ahead pr.CommitsBehind = divergence.Behind + log.Debug("Got divergence: pr [%d] in %-v", pr.Index, pr.BaseRepo) + if err := pr.UpdateColsIfNotMerged("merge_base", "status", "conflicted_files", "base_branch", "c> return err } + log.Debug("UpdatedCols: pr [%d] in %-v", pr.Index, pr.BaseRepo) // Create comment options := &models.CreateCommentOptions{ ```

GiteaMirror commented

2025-11-02 06:28:52 -06:00

@stale[bot] commented on GitHub (Aug 16, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Aug 16, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

2025-11-02 06:28:52 -06:00

@stale[bot] commented on GitHub (Aug 31, 2020):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Aug 31, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror commented

2025-11-02 06:28:53 -06:00

@tsynaev commented on GitHub (Aug 31, 2020):

I have the same issue. I cannot build Gitea from source code. Can someone make the patched version for windows for my test?

@tsynaev commented on GitHub (Aug 31, 2020): I have the same issue. I cannot build Gitea from source code. Can someone make the patched version for windows for my test?

GiteaMirror commented

2025-11-02 06:28:53 -06:00

@dseynaev commented on GitHub (Nov 2, 2020):

we are also seeing this running in docker (gitea/gitea:1.11.8) with a postgresql backend

@dseynaev commented on GitHub (Nov 2, 2020): we are also seeing this running in docker (gitea/gitea:1.11.8) with a postgresql backend

GiteaMirror commented

2025-11-02 06:28:53 -06:00

@zeripath commented on GitHub (Nov 2, 2020):

could you please upgrade to the latest version (currently 1.12.5) and see if this occurs on that version.

@zeripath commented on GitHub (Nov 2, 2020): could you please upgrade to the latest version (currently 1.12.5) and see if this occurs on that version.

GiteaMirror referenced this issue

2025-11-02 16:11:33 -06:00

[PR #5557] [MERGED] Synchronize SSH keys on login with LDAP + Fix SQLite deadlock on ldap ssh key deletion #17841

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#5557