github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-22 06:24:14 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Huge pull request creation timeout #11976

New Issue
Closed
opened 2025-11-02 09:53:23 -06:00 by GiteaMirror · 9 comments
GiteaMirror commented 2025-11-02 09:53:23 -06:00
Owner
Copy Link

Originally created by @TitaniumHocker on GitHub (Nov 8, 2023).

Description

I have huge pull request with more that 1kk diff lines and it always fails with timeout.
I raised the timeout on the reverse proxy side to 5 minutes, and then to 10 minutes, but this did not help. I don’t know if there is any point in raising the timeout anymore.

Here is some errors from logs:

Nov 08 17:04:46 gitea-hostname gitea[699]: 2023/11/08 17:04:46 ...ll/patch_unmerged.go:164:unmergedFiles() [E] Unable to run ls-files -u -z! Error: git ls-files -u -z: context deadline exceeded
Nov 08 17:04:46 gitea-hostname gitea[699]: 2023/11/08 17:04:46 ...ers/web/repo/pull.go:1297:CompareAndPullRequestPost() [E] NewPullRequest: signal: killed

I tried to add more RAM and CPU to VM, but it doesn't help. Judging by htop, this operation does not waste a lot of resources.

Gitea Version

1.20.5

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

gateway-timeout
gitea-timeout

Git Version

2.30.2

Operating System

Debian 11

How are you running Gitea?

Selfhosted with systemd unit, downloaded from releases page on github.
VM instance has 8GB of RAM and 4 vCPU.

Database

PostgreSQL

Originally created by @TitaniumHocker on GitHub (Nov 8, 2023). ### Description I have huge pull request with more that 1kk diff lines and it always fails with timeout. I raised the timeout on the reverse proxy side to 5 minutes, and then to 10 minutes, but this did not help. I don’t know if there is any point in raising the timeout anymore. Here is some errors from logs: ``` Nov 08 17:04:46 gitea-hostname gitea[699]: 2023/11/08 17:04:46 ...ll/patch_unmerged.go:164:unmergedFiles() [E] Unable to run ls-files -u -z! Error: git ls-files -u -z: context deadline exceeded Nov 08 17:04:46 gitea-hostname gitea[699]: 2023/11/08 17:04:46 ...ers/web/repo/pull.go:1297:CompareAndPullRequestPost() [E] NewPullRequest: signal: killed ``` I tried to add more RAM and CPU to VM, but it doesn't help. Judging by htop, this operation does not waste a lot of resources. ### Gitea Version 1.20.5 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ![gateway-timeout](https://github.com/go-gitea/gitea/assets/37049574/c1c9f098-1a56-4af0-8bb5-479b0a53abf6) ![gitea-timeout](https://github.com/go-gitea/gitea/assets/37049574/8cb77eb8-42db-4443-afb3-d20cadf2c7fd) ### Git Version 2.30.2 ### Operating System Debian 11 ### How are you running Gitea? Selfhosted with systemd unit, downloaded from releases page on github. VM instance has 8GB of RAM and 4 vCPU. ### Database PostgreSQL
GiteaMirror added the performance/speedtype/bug labels 2025-11-02 09:53:23 -06:00
GiteaMirror commented 2025-11-02 09:53:24 -06:00
Author
Owner
Copy Link

@KN4CK3R commented on GitHub (Nov 8, 2023):

You may need to adjust these timeouts:
69d98f83f9/custom/conf/app.example.ini (L700-L707)

@KN4CK3R commented on GitHub (Nov 8, 2023): You may need to adjust these timeouts: https://github.com/go-gitea/gitea/blob/69d98f83f9a62a7e70976b5d973f293f73e42266/custom/conf/app.example.ini#L700-L707
GiteaMirror commented 2025-11-02 09:53:24 -06:00
Author
Owner
Copy Link

@TitaniumHocker commented on GitHub (Nov 9, 2023):

You may need to adjust these timeouts:

I don't see timeout for git ls-files in this list. Besides, my operation timeouts on reverse proxy side. I don't want to increase timeouts - 10 minutes alreary too much.

@TitaniumHocker commented on GitHub (Nov 9, 2023): > You may need to adjust these timeouts: I don't see timeout for `git ls-files` in this list. Besides, my operation timeouts on reverse proxy side. I don't want to increase timeouts - 10 minutes alreary too much.
GiteaMirror commented 2025-11-02 09:53:24 -06:00
Author
Owner
Copy Link

@KN4CK3R commented on GitHub (Nov 9, 2023):

git ls-files uses the DEFAULT timeout setting.

@KN4CK3R commented on GitHub (Nov 9, 2023): `git ls-files` uses the `DEFAULT` timeout setting.
GiteaMirror commented 2025-11-02 09:53:24 -06:00
Author
Owner
Copy Link

@TitaniumHocker commented on GitHub (Nov 9, 2023):

git ls-files uses the DEFAULT timeout setting.

Seems like it doesn't work, process fails on reverse proxy timeout in 10 minutes, not in 6 minutes with default value.

@TitaniumHocker commented on GitHub (Nov 9, 2023): > git ls-files uses the DEFAULT timeout setting. Seems like it doesn't work, process fails on reverse proxy timeout in 10 minutes, not in 6 minutes with default value.
GiteaMirror commented 2025-11-02 09:53:25 -06:00
Author
Owner
Copy Link

@lschwahn commented on GitHub (Nov 27, 2023):

Hi,

we are observing a similar behavior:

In our case it's not, that the pull request itself is that big. But the amount of files identified by following Function ist ~ 1000.
709a376c51/services/pull/patch_unmerged.go (L57)

Because of this the following loop runs several minutes, resulting in a timeout because of our Reverse-Proxy (which was set to
60 secs).

709a376c51/services/pull/patch_unmerged.go (L161)

We set the reverse-proxy timeout to 6 Minutes, to match the gitea default timeout values. As a workaround this "resolved" the
Proxy-Timeout-Errors. But the time spent to create a pull request is still not satisfying.

Gitea Version
1.21.0

Git Version
2.40

Operating System
Rocky-Linux 8

How are you running Gitea?
Docker. We reproduced the behavior on three different machines with Rocky Linux 8 installed:

PowerEdge R630: CPU: 2 * Intel Xeon E5-2630 v3 (2.4GHz; 8 Cores), Storage: SAS, Memory: 128GB
PowerEdge R740: CPU: 2* Intel Xeon Gold 6126 (2.6GHz; 12 Cores), Storage: NVMe, Memory: 768GB
Virtual Server (Hyper-V): CPU: 4 Cores, Memory: 8GB

Database
MariaDB

@lschwahn commented on GitHub (Nov 27, 2023): Hi, we are observing a similar behavior: In our case it's not, that the pull request itself is that big. But the amount of files identified by following Function ist ~ 1000. https://github.com/go-gitea/gitea/blob/709a376c518d0cfde10bb911b32fd0ea82c67b52/services/pull/patch_unmerged.go#L57 Because of this the following loop runs several minutes, resulting in a timeout because of our Reverse-Proxy (which was set to 60 secs). https://github.com/go-gitea/gitea/blob/709a376c518d0cfde10bb911b32fd0ea82c67b52/services/pull/patch_unmerged.go#L161 We set the reverse-proxy timeout to 6 Minutes, to match the gitea default timeout values. As a workaround this "resolved" the Proxy-Timeout-Errors. But the time spent to create a pull request is still not satisfying. **Gitea Version** 1.21.0 **Git Version** 2.40 **Operating System** Rocky-Linux 8 **How are you running Gitea?** Docker. We reproduced the behavior on three different machines with Rocky Linux 8 installed: PowerEdge R630: CPU: 2 * Intel Xeon E5-2630 v3 (2.4GHz; 8 Cores), Storage: SAS, Memory: 128GB PowerEdge R740: CPU: 2* Intel Xeon Gold 6126 (2.6GHz; 12 Cores), Storage: NVMe, Memory: 768GB Virtual Server (Hyper-V): CPU: 4 Cores, Memory: 8GB **Database** MariaDB
GiteaMirror commented 2025-11-02 09:53:25 -06:00
Author
Owner
Copy Link

@achepukov commented on GitHub (Apr 4, 2024):

As a workaround you can create PR based on branch equals to base branch, and then push new commits into it.

@achepukov commented on GitHub (Apr 4, 2024): As a workaround you can create PR based on branch equals to base branch, and then push new commits into it.
GiteaMirror commented 2025-11-02 09:53:25 -06:00
Author
Owner
Copy Link

@bartvdbraak commented on GitHub (Jun 26, 2024):

We're also running into this issue, unfortunately.

Even with:

[git.timeout]
DEFAULT = 600
@bartvdbraak commented on GitHub (Jun 26, 2024): We're also running into this issue, unfortunately. Even with: ``` [git.timeout] DEFAULT = 600 ```
GiteaMirror commented 2025-11-02 09:53:25 -06:00
Author
Owner
Copy Link

@brechtvl commented on GitHub (Jun 27, 2024):

It appears that running git update-index --remove for every individual file is slow. Batching them all together is much faster.

I have a change here that helps for file removal, but not file addition yet. I won't have time to finish this, but maybe someone else will pick it up.
https://github.com/blender/gitea/commits/fix-slow-check-many-files/

@brechtvl commented on GitHub (Jun 27, 2024): It appears that running `git update-index --remove` for every individual file is slow. Batching them all together is much faster. I have a change here that helps for file removal, but not file addition yet. I won't have time to finish this, but maybe someone else will pick it up. https://github.com/blender/gitea/commits/fix-slow-check-many-files/
GiteaMirror commented 2025-11-02 09:53:25 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 5, 2024):

Duplicate of #31600

@lunny commented on GitHub (Dec 5, 2024): Duplicate of #31600
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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
Mirrored from GitHub 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
No Label performance/speed type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#11976
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?