Skip to content
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

500 error when when trying to transfer repository from user to organization #17044

Closed
2 of 6 tasks
witten opened this issue Sep 14, 2021 · 7 comments · Fixed by #17049
Closed
2 of 6 tasks

500 error when when trying to transfer repository from user to organization #17044

witten opened this issue Sep 14, 2021 · 7 comments · Fixed by #17049
Milestone

Comments

@witten
Copy link

witten commented Sep 14, 2021

  • Gitea version (or commit ref): 1.15.2
  • Git version: 2.30.2 (as part of Gitea container)
  • Operating system: Debian 11 running official Gitea Docker container (based on Alpine 3.13.6), run via Docker Compose
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Browser: Firefox 91.0.2 (ad blockers disabled)
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No (tried moving a test repository to a pre-existing test organization)
  • Log gist: https://gist.github.com/witten/5ee4772a7031ea5d6ce6e45ffa61e9ce

Description

When trying to transfer a repository from my user to an organization I own, I receive a 500 from Gitea and the transfer doesn't go through.

Potentially relevant: #10230

Screenshots

bug1

bug2

HTTP request payload

_csrf=REDACTED&action=transfer&repo_name=borgmatic&new_owner_name=borgmatic-collective
@zeripath
Copy link
Contributor

Please read https://docs.gitea.io/en-us/logging-configuration/#debugging-problems

We need the logs for the 500

@witten
Copy link
Author

witten commented Sep 14, 2021

I've just updated the linked gist as per your debugging instructions. It looks like the error in question is this:

2021/09/14 17:38:43 .../web/repo/setting.go:593:SettingsPost() [E] TransferOwnership: getCollaborators: user does not exist [uid: 38, name: , keyid: 0]

@zeripath
Copy link
Contributor

zeripath commented Sep 14, 2021

OK so the error report is coming from:

ctx.ServerError("TransferOwnership", err)

but the error is actually created:

return fmt.Errorf("getCollaborators: %v", err)

and will actually come from:

user, err := getUserByID(e, c.UserID)
if err != nil {
return nil, err
}

Now the interesting part here is that this implies that there is a user (user id: 38) who is listed as a collaborator of that repo who is no longer in existence.

This is a db consistency issue but I think we should just handle this by ignoring this user.

@witten
Copy link
Author

witten commented Sep 14, 2021

Interesting! I deleted a bunch of a spammers a while back, and it's possible that impacted a collaborator on the repo in question. So maybe this is a non-issue for other Gitea instances?

@zeripath
Copy link
Contributor

Well it's kinda bad that this kills things - we should simply tolerate and not die.

I also don't think that our doctor will fix this inconsistency either so that needs fixing too.

@zeripath
Copy link
Contributor

I think you could probably just manually remove the collaborator with that userid from the table directly and the problem will go away for you however we need to fix this so leave this bug open and PR will close it.

@witten
Copy link
Author

witten commented Sep 14, 2021

Got it! I confirmed that deleting the dangling collaborator from the collaboration table fixed the problem, and I'm now able to transfer the repository successfully. I'll leave this ticket open for the PR.

Thanks for your help!

zeripath added a commit to zeripath/gitea that referenced this issue Sep 14, 2021
It is possible to have a collaboration in a repository which refers to a no-longer
existing user. This causes the repository transfer to fail with an unusual error.

This PR makes `repo.getCollaborators()` nicely handle the missing user by ghosting
the collaboration but also adds consistency check. It also adds an
Access consistency check.

Fix go-gitea#17044

Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath added a commit that referenced this issue Sep 27, 2021
* Nicely handle missing user in collaborations

It is possible to have a collaboration in a repository which refers to a no-longer
existing user. This causes the repository transfer to fail with an unusual error.

This PR makes `repo.getCollaborators()` nicely handle the missing user by ghosting
the collaboration but also adds consistency check. It also adds an
Access consistency check.

Fix #17044

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
zeripath added a commit to zeripath/gitea that referenced this issue Sep 27, 2021
Backport go-gitea#17049

It is possible to have a collaboration in a repository which refers to a no-longer
existing user. This causes the repository transfer to fail with an unusual error.

This PR makes `repo.getCollaborators()` nicely handle the missing user by ghosting
the collaboration but also adds consistency check. It also adds an
Access consistency check.

Fix go-gitea#17044

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
@zeripath zeripath added this to the 1.15.4 milestone Sep 27, 2021
zeripath added a commit that referenced this issue Sep 28, 2021
Backport #17049

It is possible to have a collaboration in a repository which refers to a no-longer
existing user. This causes the repository transfer to fail with an unusual error.

This PR makes `repo.getCollaborators()` nicely handle the missing user by ghosting
the collaboration but also adds consistency check. It also adds an
Access consistency check.

Fix #17044

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants