Description
Description
We are operating a Gitea stack via Podman containers built from the official Docker images (Gitea: 1.22.0, MySQL 8.0.32). The containers are both operating on the same machine in the same Podman pod. So there should be minimal implication of the network unless I'm missing something.
When attempting to make a fork via the Web UI, the page waits for a response for a long time; typically around 3 minutes. This is happening when forking a repository with a disk size of 1.4 GB when cloned to the local machine. It is also observed on other repos, but the time scales with size.
The weird thing is, while I would typically credit this to the repo size, I noticed the fork operation seems to occur relatively quickly. I see a POST response in the container logs for the fork operation in about 3 seconds. I verified that, in a separate tab, I can see the repo fork on my profile long before the fork UI has redirected.
In the logs, I see the 303 response for the redirect of the fork UI come in at that close to 3 minute mark.
I monitored the resource usage of the host and the Gitea/MySQL containers and they appeared to be minimally utilized. I dropped into a MySQL CLI within the MySQL container just to check that queries execute quickly and they do.
So with all that, I wanted to submit an issue in case you had some advice or there was a bug at play here. We're on RHEL 8.5 and this issue was observed in Firefox 128.0.2 and Seamonkey 2.53.10.1.
Gitea Version
1.22.0
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
2.45.1
Operating System
RHEL8.5 running containers, built from Gitea official images that use alpine.
How are you running Gitea?
See details above:
RHEL8.5 host.
Podman containers built from Official Gitea Docker images.
Database
MSSQL