github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-17 06:32:41 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

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

New Issue
Closed
opened 2025-11-02 05:24:43 -06:00 by GiteaMirror · 7 comments
GiteaMirror commented 2025-11-02 05:24:43 -06:00
Owner
Copy Link

Originally created by @SlavekB on GitHub (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

Originally created by @SlavekB on GitHub (Aug 13, 2019). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): 1.9.0 - Git version: 2.11.0 - Operating system: Debian 9.9 - Database (use `[x]`): - [ ] PostgreSQL - [x] 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 <!-- **If this issue involves the Web Interface, please include a screenshot** --> https://mirror.git.trinitydesktop.org/gitea/TDE/gtk-qt-engine/pulls/2
GiteaMirror added the issue/confirmedtype/bug labels 2025-11-02 05:24:43 -06:00
GiteaMirror commented 2025-11-02 05:24:44 -06:00
Author
Owner
Copy Link

@SlavekB commented on GitHub (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

@SlavekB commented on GitHub (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
GiteaMirror commented 2025-11-02 05:24:44 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Aug 14, 2019):

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

@lunny commented on GitHub (Aug 14, 2019): We should display who merged the PR and the last commit id.
GiteaMirror commented 2025-11-02 05:24:44 -06:00
Author
Owner
Copy Link

@SlavekB commented on GitHub (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

@SlavekB commented on GitHub (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
GiteaMirror commented 2025-11-02 05:24:45 -06:00
Author
Owner
Copy Link

@guillep2k commented on GitHub (Sep 23, 2019):

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.

@guillep2k commented on GitHub (Sep 23, 2019): 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.
GiteaMirror commented 2025-11-02 05:24:45 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (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[bot] commented on GitHub (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.
GiteaMirror commented 2025-11-02 05:24:45 -06:00
Author
Owner
Copy Link

@SlavekB commented on GitHub (Nov 22, 2019):

Issue is still valid for the current Gitea 1.10.0 release.

@SlavekB commented on GitHub (Nov 22, 2019): Issue is still valid for the current Gitea 1.10.0 release.
GiteaMirror commented 2025-11-02 05:24:45 -06:00
Author
Owner
Copy Link

@SlavekB commented on GitHub (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 commented on GitHub (Jul 22, 2021): Because I didn't watch this problem in current versions for a long time, it seems that it can be closed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/confirmed type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#3773
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?