Gitea incorrectly auto-closes issue even though referenced branch has not been merged yet

[reimer-atb]

Description

Gitea incorrectly auto-closes an issue if you force-push to a PR referencing that issue, even though the PR is still open and not merged into the main branch.

Steps to reproduce

1. Create a repo with a single file README.md.

2. Create issue "A" in that repo

3. Create a new branch "<issue_number>-A" for the issue, add some changes to README.md, commit them with message "closes #<issue_number>" to enable auto-close when the branch is merged, and push it

4. Create a pull request based on branch "<issue_number>-A" above

5. Link the issue to the pull request branch "<issue_number>-A"

   

6. Create a second branch "B" based on "main", add a change to README.md that conflicts with a change in branch "<issue_number>-A", and push it

7. Create a pull request for the second branch "B", and merge it using "Rebase
   then fast-forward" and selecting "Delete Branch "B""

8. Pull the updated "main" branch locally, switch to branch "<issue_number>-A", and run git rebase main

9. Resolve the conflict in README.md keeping both changes, and run git add README.md, then git rebase --continue

10. Run git push --force-with-lease

Result

Issue "A" is auto-closed (see https://demo.gitea.com/reimer-atb/test/issues/1)

even though the PR is still open and branch "<issue_number>-A" has not been merged into "main" (see https://demo.gitea.com/reimer-atb/test/pulls/2).

Expected result

Issue "A" should remain "open". It should only be auto-closed when the PR is merged into "main".

Gitea Version

1.23.5 and 1.24.0+dev-424-g403775e74e

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.49.0

Operating System

No response

How are you running Gitea?

I used demo.gitea.com. It also happens on our gitea instance (version 1.23.5). But I don't manage that and don't know what it runs on.

Database

None

[wxiaoguang]

That branch selector does nothing more than just record/display a name. It affects nothing.

That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar #32744 "

[reimer-atb]

That branch selector does nothing more than just record/display a name. It affects nothing.

It obviously causes a bug in the auto-closing issue feature. Because the issue is not auto-closed if I don't link the issue to the pull request branch.

That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar #32744 "

While the mentioned PR may have been merged it does not seem to be included in any of the upcoming releases (1.23.6 or 1.24)?

There's also #20226 (included in the 1.24.0 milestone). Won't that require again a link between issue and pull request branch?

[wxiaoguang]

While the mentioned PR may have been merged it does not seem to be included in any of the upcoming releases (1.23.6 or 1.24)?

Because that PR didn't really remove the selector. See its discussion, a user said that they still need that selector.

There's also #20226 (included in the 1.24.0 milestone). Won't that require again a link between issue and pull request branch?

That's a new proposal

[reimer-atb]

Because that PR didn't really remove the selector. See its discussion, a user said that they still need that selector.

Then I don't understand the relevance for this issue? If the branch selector is not going to be removed then the bug I am describing here remains, and should be fixed.

[wxiaoguang]

Hmm, I think I could overall understand the problem now.

It seems to be a feature from "Fix permission checks for close/reopen from commit (#8875)"

The logic is like this: if an issue #N refers to branch-X, and branch-X contains commits like close #N, then when Gitea receives the commit, then it auto closes the issue #N.

Actually you could also reproduce it by this step:

• Create issue #N
• Create branch branch-X
• Use the branch selector to make issue #N refer to branch-X
• Add a commit close #N in branch-X and push
• Then issue #N will be closed

I guess it can't be considered as a bug since it was designed to work that way, some users used to follow this workflow.

By the way, there is even an option in repo's setting page: "Close an issue via a commit made in a non default branch", it could close an issue by a commit in any branch (but not only the "referred" one) by close #N phrase.

---

So maybe the solution is: do not use that branch selector if you don't need it .........

---

Related logic:

gitea/services/repository/push.go

Line 249 in 39fc2e7

if err := issue_service.UpdateIssuesCommit(ctx, pusher, repo, commits.Commits, refName); err != nil {

gitea/services/issue/commit.go

Line 199 in 39fc2e7

if err := CloseIssue(ctx, refIssue, doer, c.Sha1); err != nil {

[reimer-atb]

By the way, there is even an option in repo's setting page: "Close an issue via a commit made in a non default branch", it could close an issue by a commit in any branch (but not only the "referred" one) by close #N phrase.

The point is that I did not enable that setting. And therefore expected that having closes #N in a commit only closes the issue if the commit is on the default branch.

At the very least, the wording of that option is not clear, and gitea's behavior is inconsistent. Because if I just do a normal push of a closes #N commit to my non-default branch-X the issue will be kept open. Only when I do a force-push to that branch after a rebase the issue get's auto-closed. That does not make any sense to me, in any workflow.

[wxiaoguang]

The point is that I did not enable that setting. And therefore expected that having closes #N in a commit only closes the issue if the commit is on the default branch.

I did not say you enabled that setting. I was just explaining the whole design. I think I have said clearly that By the way (but not only ...).

Because if I just do a normal push of a closes #N commit to my non-default branch-X the issue will be kept open.

Please read the explanation above again: a commit in branch branch-X contains close #N will close the issue #N if the issue has attached to branch branch-X by the sidebar branch selector. I was just explaining the old design.

Only when I do a force-push to that branch after a rebase the issue get's auto-closed. That does not make any sense to me, in any workflow.

That's not true. A normal push also also behaves exactly the same: a commit in branch branch-X contains close #N will close the issue #N if the issue has attached to branch branch-X by the sidebar branch selector. You could try it by yourself without force-push.

[wxiaoguang]

And actually I do not know why you need that branch selector to choose a branch for an issue.

So quote the comment above:

So maybe the solution is: do not use that branch selector if you don't need it .........

If you really need it, could you help to elaborate your workflow?

[reimer-atb]

I don't really need it. And yes, now that I know that the branch selection feature is causing the bug I can work around it and not use the branch selector.

But I don't understand what point you are trying to make here? Are you saying this is not a bug? Then I would strongly disagree.

As long as this branch selection feature exists some people will use it. And they will encounter this bug that I am describing. And they will become confused and frustrated with gitea.

[wxiaoguang]

But I don't understand what point you are trying to make here? Are you saying this is not a bug? Then I would strongly disagree.

Then it comes to that background:

That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar #32744 "

😆

In my mind that "branch selector" is an out-dated feature, it was designed that way so it's hard to say it is really a bug or not. But I failed to remove it because some users said they still need it .....

As an open-source and crowd-contributed project, many features were written in old days and the original author maintainers are not active anymore. I am just trying to clarify everything at the moment.

To be honest, I don't quite understand how to correctly maintain this feature to satisfy every user.