Closed zcopado closed 2 months ago
What are the values for git timeout in your ini? https://docs.gitea.com/administration/config-cheat-sheet#git---timeout-settings-gittimeout
Good question! We have not altered any of the DEFAULTS. So whatever the defaults are, as per the app.example.ini, that's what we have.
And funny enough, none of them, other than GC (garbage collection) elude to a 60s timeout. Hence why we are perplexed.
Still you could add higher values to your config and test if it works. You can see the current settings on the admin panel /admin/config
. Just to be sure there are no other values set at the moment.
Good point. What timeout would affect this action? None of them seem to have a clear correlation...
It's the default value.
Alright... that value is set to 360 seconds (6 minutes). This operation is failing at ~60s... what value should we tweak here?
Maybe you are using a reverse proxy like nginx and its default timeout is also 60s
Great point, wxiaoguang... we checked, and our ingress has a 300s timeout. Additionally, can someone with more familiarity with the 'context' in gitea explain what causes the 'context canceled'?
Perhaps it is a timeout of the context, in regard to PullRequest, that is causing this issue.
context canceled
is caused by the "Context is cancelled before the operation finishes". It could occur:
CompareAndPullRequestPost
and NewPullRequest
use the ctx
from the reuqest, aka http web connection
). So if the connection is closed, the context is canceledCompareAndPullRequestPost() [E] [66b3414f] NewPullRequest: context canceled
, that's why I guess it is caused by reverse proxy's read/write timeout -- the default value is 60s.I think there is an easy way to to confirm whether it is really caused by the network connection, when the error occurs:
Great points @wxiaoguang ... thank you for the insight. We will dig deeper on our end, and report back our findings. Truly appreciate the clarity.
@wxiaoguang - Your insight was correct. In our ingress configuration (utilizing nginx), there was an implied setting with a default value:
Syntax: | proxy_read_timeout time;
----
proxy_read_timeout 60s; #default
http, server, location
We explicit set that directive, with a value of 300s, and Boom! Everything worked as expected.
Closing this Issue. Cheers.
Description
We have found that various Pull Requests are failing with a 500 Internal Server Error after >60s of executing the CompareAndPullRequestPost (pull.go).
Here are the typical, overall events we get:
In between these anchor events are a myriad of "merge" events, as follows:
And here are the [E]rror events RIGHT BEFORE the final 500 Internal Server Error event:
The interesting part of this is that we UPGRADED this instance TODAY to v1.20.6, and it did not fix this problem.
Prior to the upgrade, we were running v1.18.5, and had the same results (with some different events BEFORE the end):
We need your help. We have scoured your Issues lists, Discord, etc, and cannot locate anything that would help us here.
We are looking for anything to explain the context canceled events, and how we can extend "what seems to be" a 60s timeout for the Pull Request creation, or the context lifetime.
Thank you for ALL your help.
Gitea Version
1.20.6
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
2.40.1
Operating System
alpine 3.18
How are you running Gitea?
In a GKE v1.28+ Cluster
Successfully running gitea since v1.16+
Database
PostgreSQL