Updating issues via API does not work if "state" field is present but unchanged

[splitt3r]

Description

If i try to update an issue via:

curl --location --request PATCH 'http://localhost:3000/api/v1/repos/root/test/issues/1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer ***' \
--data '{
  "assignees": [],
  "body": "Test 123",
  "title": "Dependency Dashboard",
  "state": "open"
}'

The issue is updated just fine but Gitea returns status code 500.

The problem here is the state field. Without the state field everything works just fine.

I think the problem was introduced with a50026e#diff-f33622667aa80c1735ccaef8e7331422504e8c449f691c6847ec4f6737a278cd. @yp05327 maybe you can have a look at it.

The problem occured because Renovate Bot useses the state field in its model (see https://github.com/renovatebot/renovate/blob/main/lib/modules/platform/gitea/types.ts#L171-L176) for issue creation / update via the Gitea API.

Gitea Version

1.22.1

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

The logs:

2024/08/19 07:11:13 ...api/v1/repo/issue.go:894:EditIssue() [E] ChangeStatus: Issue [1] 0 was already closed
2024/08/19 07:11:13 ...eb/routing/logger.go:102:func1() [I] router: completed PATCH /api/v1/repos/root/test/issues/1 for 172.17.0.1:36648, 500 Internal Server Error in 33.5ms @ repo/issue.go:742(repo.EditIssue)

The API returns:

{
    "message": "Issue [1] 0 was already closed",
    "url": "http://localhost:3000/api/swagger"
}

Git Version

No response

Operating System

No response

How are you running Gitea?

Docker

Database

SQLite

[yp05327]

Thanks for your report. I will check it later.

[yp05327]

I got this error. But the issue is opening not closed.

I think it is not related to the changes you mentioned. It looks that this is an old bug.

Nothing should be performed if current status is same as target status

The logic here is a bit strange, nothing should be performed but it returns issue/PR closed error. 😕
I need to figure out where these codes come from, I have no time today, I will do it tomorrow.

[yp05327]

Emmm, this logic can be traced far before (about 5 years ago). No need to figure out it any more, just need to find a solution to fix it.

[yp05327]

I see. It was part of my fault. But I still think the logic in changeIssueStatus is strange.

[splitt3r]

@yp05327 thanks for the quick fix. Great work 👍🏻