Skip to content

Confusing information about the user who merged pull-request #7843

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 of 7 tasks
SlavekB opened this issue Aug 13, 2019 · 7 comments
Closed
1 of 7 tasks

Confusing information about the user who merged pull-request #7843

SlavekB opened this issue Aug 13, 2019 · 7 comments
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug

Comments

@SlavekB
Copy link

SlavekB commented Aug 13, 2019

  • Gitea version (or commit ref): 1.9.0
  • Git version: 2.11.0
  • Operating system: Debian 9.9
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

When pull-request is merged, everything goes well, but the activity information states that the pull request was closed at the same time by both the user who actually did and the user who created the pull-request, which is confusing.

It started to happen after upgrade to 1.9.0.

Screenshots

https://mirror.git.trinitydesktop.org/gitea/TDE/gtk-qt-engine/pulls/2

@SlavekB
Copy link
Author

SlavekB commented Aug 14, 2019

Other examples - this time the same user is mentioned twice because the merge was performed by the same user who created the pull-request:

https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/pulls/48
https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/56

@lunny
Copy link
Member

lunny commented Aug 14, 2019

We should display who merged the PR and the last commit id.

@SlavekB
Copy link
Author

SlavekB commented Aug 31, 2019

Another strange example: As the name of the user who closed the pull request is used the name of the organization:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/19

@guillep2k
Copy link
Member

Apparently there is a race condition when the TestPullRequest() goroutine is closing the issue even when it was closed moments before. Here are my stack traces for a single merge (break point on changeStatus()):

First time :

code.gitea.io/gitea/models.(*Issue).changeStatus (\home\gprandi\src\code.gitea.io\gitea\models\issue.go:779)
code.gitea.io/gitea/models.(*PullRequest).SetMerged (\home\gprandi\src\code.gitea.io\gitea\models\pull.go:437)
code.gitea.io/gitea/modules/pull.Merge (\home\gprandi\src\code.gitea.io\gitea\modules\pull\merge.go:265)
code.gitea.io/gitea/routers/repo.MergePullRequest (\home\gprandi\src\code.gitea.io\gitea\routers\repo\pull.go:679)

Second time:

code.gitea.io/gitea/models.(*Issue).changeStatus (\home\gprandi\src\code.gitea.io\gitea\models\issue.go:724)
code.gitea.io/gitea/models.(*PullRequest).SetMerged (\home\gprandi\src\code.gitea.io\gitea\models\pull.go:437)
code.gitea.io/gitea/models.(*PullRequest).manuallyMerged (\home\gprandi\src\code.gitea.io\gitea\models\pull.go:477)
code.gitea.io/gitea/models.TestPullRequests (\home\gprandi\src\code.gitea.io\gitea\models\pull.go:1277)

I know #6233 is supposed to prevent changeStatus() from closing the issue twice, but the fact that there are two different transactions dealing with the same record makes them both see it as not closed. Some kind of lock should be used to prevent this.

I still don't quite understand the logic behind TestPullRequest() but in absence of another solution, it might be possible to prevent this if we make TestPullRequest() to ignore commits younger than 10 seconds or something like that.

@stale
Copy link

stale bot commented Nov 22, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale stale bot added the issue/stale label Nov 22, 2019
@zeripath zeripath added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label Nov 22, 2019
@stale stale bot removed the issue/stale label Nov 22, 2019
@SlavekB
Copy link
Author

SlavekB commented Nov 22, 2019

Issue is still valid for the current Gitea 1.10.0 release.

@SlavekB
Copy link
Author

SlavekB commented Jul 22, 2021

Because I didn't watch this problem in current versions for a long time, it seems that it can be closed.

@SlavekB SlavekB closed this as completed Jul 22, 2021
@go-gitea go-gitea locked and limited conversation to collaborators Oct 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Projects
None yet
Development

No branches or pull requests

5 participants