Opening a PR in 1.17.0 results in a 500 error #9322

Closed
opened 2025-11-02 08:35:23 -06:00 by GiteaMirror · 1 comment
Owner

Originally created by @Toxik1983 on GitHub (Aug 2, 2022).

Description

After migrating to version 1.17.0, some newly created PRs as well as some PRs that were previously created in version 1.16.9 now won't open and always result in a 500 error.
The logs always show the same error when trying to open an affected PR:

2022/08/02 10:07:13 ...vices/pull/update.go:109:IsUserAllowedToUpdate() [E] [62e8db31] pr.BaseRepo.GetUnit(unit.TypePullRequests): Unit type does not exist: TypePullRequests
2022/08/02 10:07:13 ...ers/web/repo/pull.go:509:PrepareViewPullInfo() [E] [62e8db31] IsUserAllowedToUpdate: Unit type does not exist: TypePullRequests
2022/08/02 10:07:13 [62e8db31] router: completed GET /-redacted-/backoffice-api/pulls/2323 for -redacted-:50108, 500 Internal Server Error in 135.1ms @ repo/issue.go:1122(repo.ViewIssue)

This seems to be the case for all PRs that originate from the fork of a user where, at least after migrating to 1.17.0, 'Enable Repository Pull Requests' is no longer enabled in the fork's Repository settings.
After (re-)enabling this option, the 500 error no longer occurs for PRs originating from that specific fork.

Gitea Version

1.17.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Official Docker image on Ubuntu Server

Database

No response

Originally created by @Toxik1983 on GitHub (Aug 2, 2022). ### Description After migrating to version 1.17.0, some newly created PRs as well as some PRs that were previously created in version 1.16.9 now won't open and always result in a 500 error. The logs always show the same error when trying to open an affected PR: ``` 2022/08/02 10:07:13 ...vices/pull/update.go:109:IsUserAllowedToUpdate() [E] [62e8db31] pr.BaseRepo.GetUnit(unit.TypePullRequests): Unit type does not exist: TypePullRequests 2022/08/02 10:07:13 ...ers/web/repo/pull.go:509:PrepareViewPullInfo() [E] [62e8db31] IsUserAllowedToUpdate: Unit type does not exist: TypePullRequests 2022/08/02 10:07:13 [62e8db31] router: completed GET /-redacted-/backoffice-api/pulls/2323 for -redacted-:50108, 500 Internal Server Error in 135.1ms @ repo/issue.go:1122(repo.ViewIssue) ``` This seems to be the case for all PRs that originate from the fork of a user where, at least after migrating to 1.17.0, 'Enable Repository Pull Requests' is no longer enabled in the fork's Repository settings. After (re-)enabling this option, the 500 error no longer occurs for PRs originating from that specific fork. ### Gitea Version 1.17.0 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Official Docker image on Ubuntu Server ### Database _No response_
GiteaMirror added the type/bug label 2025-11-02 08:35:23 -06:00
Author
Owner

@zeripath commented on GitHub (Aug 17, 2022):

This seems to be the case for all PRs that originate from the fork of a user where, at least after migrating to 1.17.0, 'Enable Repository Pull Requests' is no longer enabled in the fork's Repository settings.
After (re-)enabling this option, the 500 error no longer occurs for PRs originating from that specific fork.

From what version of Gitea were you migrating from? How old was the fork? Was the fork working on the previous version?

Are there any other forks affected?

Do you have a backup of your db from before the migration that you could check the contents of the repo_units table for that repository?

There are no migrations in 1.17 that would cause the repo_units here to change - although we may now actually be testing for the presence. So it's probably that the repo_unit for PullRequests was never set and the repo should never been allowed to do PRs in the first place!!


If the repo does not have the PullRequest unit set, whilst we should not 500 the best we could do in that situation is send a forbidden - which doesn't get the user much further.

@zeripath commented on GitHub (Aug 17, 2022): > This seems to be the case for all PRs that originate from the fork of a user where, at least after migrating to 1.17.0, 'Enable Repository Pull Requests' is no longer enabled in the fork's Repository settings. > After (re-)enabling this option, the 500 error no longer occurs for PRs originating from that specific fork. From what version of Gitea were you migrating from? How old was the fork? Was the fork working on the previous version? Are there any other forks affected? Do you have a backup of your db from before the migration that you could check the contents of the repo_units table for that repository? There are no migrations in 1.17 that would cause the repo_units here to change - although we may now actually be testing for the presence. So it's probably that the repo_unit for PullRequests was never set and the repo should never been allowed to do PRs in the first place!! --- If the repo does not have the PullRequest unit set, whilst we should not 500 the best we could do in that situation is send a forbidden - which doesn't get the user much further.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#9322