Merge button can be clicked multiple times, sometimes leads to HTTP 500 #9234

New Issue

GiteaMirror · 2025-11-02T08:32:54-06:00

GiteaMirror commented

2025-11-02 08:32:54 -06:00

Originally created by @informeti on GitHub (Jul 19, 2022).

Description

It seems like it is possible to click multiple times on the merge button while the merge is being processed server side. This seems to actually send multiple requests to the server.

We had one situation where the user ended up with an HTTP 500 and an inconsistent state: The changes were merged but the Pull Request in Gitea was still opened, and showed no changes anymore.
The logs showed that multiple requests to process the PR were being processed by the server, within approximately 2 seconds.
We had to correct the data in the DB for the PR to be shown as "Merged".

This issue may not be very apparent if the network connection and the server are fast. However, there are use cases where the user may have to wait few seconds. E.g. We have a hook which synchronously sends the commits to an SVN server (with Subgit); this causes a little delay which can easily reach 3-5 seconds.

To reproduce
It should be easily reproducible by creating a pre-receive.d/sleep hook which simply sleeps to add an artificial delay.

Solution idea
At least disable the merge button when it is clicked. It would also be great to have an additional, server-side check to avoid processing more than one request related to a specific PR at a time.

Gitea Version

1.17.0+rc1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Debian (but Gitea runs in the gitea/gitea:latest container)

How are you running Gitea?

Gitea runs in a Docker container (gitea/gitea:latest).

We have another container which contains a running Subgit process which synchronizes the respective Git repo with an SVN server.
In order for this to work, there's two pre-receive and two post-receive hooks. Both for pre- and post-, there's one hook that will simply call the other Subgit hook using SSH (because Subgit is running in a different container than Gitea), and then there's the actual Subgit hook that triggers the Subgit process (i.e. to send the commits to SVN if users pushed to the main branch).

This implies that a Push to the main branch will be successful and accepted only if Subgit successfully sent it to the SVN server, and only if the SVN server accepted the commit. In every other case, the Git push will be rejected.

Database

PostgreSQL

Originally created by @informeti on GitHub (Jul 19, 2022). ### Description It seems like it is possible to click multiple times on the merge button while the merge is being processed server side. This seems to actually send multiple requests to the server. We had one situation where the user ended up with an HTTP 500 and an inconsistent state: The changes were merged but the Pull Request in Gitea was still opened, and showed no changes anymore. The logs showed that multiple requests to process the PR were being processed by the server, within approximately 2 seconds. We had to correct the data in the DB for the PR to be shown as "Merged". This issue may not be very apparent if the network connection and the server are fast. However, there are use cases where the user may have to wait few seconds. E.g. We have a hook which synchronously sends the commits to an SVN server (with Subgit); this causes a little delay which can easily reach 3-5 seconds. **To reproduce** It should be easily reproducible by creating a `pre-receive.d/sleep` hook which simply sleeps to add an artificial delay. **Solution idea** At least disable the merge button when it is clicked. It would also be great to have an additional, server-side check to avoid processing more than one request related to a specific PR at a time. ### Gitea Version 1.17.0+rc1 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Debian (but Gitea runs in the gitea/gitea:latest container) ### How are you running Gitea? Gitea runs in a Docker container (`gitea/gitea:latest`). We have another container which contains a running Subgit process which synchronizes the respective Git repo with an SVN server. In order for this to work, there's two pre-receive and two post-receive hooks. Both for pre- and post-, there's one hook that will simply call the other Subgit hook using SSH (because Subgit is running in a different container than Gitea), and then there's the actual Subgit hook that triggers the Subgit process (i.e. to send the commits to SVN if users pushed to the main branch). This implies that a Push to the main branch will be successful and accepted only if Subgit successfully sent it to the SVN server, and only if the SVN server accepted the commit. In every other case, the Git push will be rejected. ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 08:32:54 -06:00

GiteaMirror closed this issue

2025-11-02 08:32:54 -06:00

GiteaMirror commented

2025-11-02 08:32:55 -06:00

@wxiaoguang commented on GitHub (Jul 22, 2022):

IMO, it's related to this one: