You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: