Gitea: Migration with pull requests from other gitea instance fails

[lakostin]

• Gitea version (or commit ref):
  1.14.0+dev-18-gd453533be
• Git version:
  2.26.2
• Operating system:
  docker Alpine Linux
• Database (use [x]):
  
  
  
  • [X] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
• Log gist:
  2020/10/22 13:25:46 ...ules/task/migrate.go:64:func1() [E] DeleteRepository: repository does not exist [id: 208, uid: 75, owner_name: , name: ]
  2020/10/22 13:25:46 modules/task/task.go:51:handle() [E] Run task failed: error while loading reactions: 403 Forbidden

Description

Migration without pull requests works fine for the same repo.
...

[6543]

looks like the account do not have access to the reactions endpoint ... - witch version the gitea instance you are migrationg from has?

[lakostin]

looks like the account do not have access to the reactions endpoint ... - witch version the gitea instance you are migrationg from has?

same version - 1.14.0+dev-18-gd453533be

[6543]

@lakostin can you tell me the url from the source, or send it to me via email if it should not get public?

[lakostin]

@lakostin can you tell me the url from the source, or send it to me via email if it should not get public?

impossible cause it's in private network

[6543]

hmm I'll try to reproduce it somehow

[6543]

@lakostin sorry could not reproduce it for now ...

[lakostin]

@lakostin sorry could not reproduce it for now ...

i tried to migrate three different pull requests and all of them failed. maybe its connected with migrations during gitea update? Firstly i had an installation of 12 version of gitea and constantly updated it until the 14 version. is there any way to check it? maybe check db relations?

[lakostin]

@6543 ?

[6543]

@lakostin you can use the "doctor" command to check and fix things (./gitea doctor --help)

and two question:

• can you see the diff via web ui on this pulls?
• was this repository already migrated from another gitea/github/... in the past?

[lakostin]

@lakostin you can use the "doctor" command to check and fix things (./gitea doctor --help)

and two question:

• can you see the diff via web ui on this pulls?

yes, diff works fine for all pull requests in all these projects

• was this repository already migrated from another gitea/github/... in the past?

no, all the repos are new

[6543]

@lakostin

... had an installation of 12 version of gitea and constantly updated it until the 14 ...

do you mean v1.12.x to v1.14.0+dev ?

If so what version sha is displayed? (example try.gitea.io show 1.14.0+dev-100-g946bbbe9b)

[lakostin]

@lakostin

... had an installation of 12 version of gitea and constantly updated it until the 14 ...

do you mean v1.12.x to v1.14.0+dev ?

yes

If so what version sha is displayed? _(example try.gitea.io show 1.14.0+dev-100-g946bbbe9b)_

1.14.0+dev-18-gd453533be

[zeripath]

OK since #13331 (that is commit 7dfb2fc) was merged you should get a little bit more helpful information regarding this issue.

In particular the issue that causes the forbidden should be displayed in the log message.

[lakostin]

2020/10/28 21:21:14 ...ules/task/migrate.go:65:func1() [E] DeleteRepository: repository does not exist [id: 4, uid: 1, owner_name: , name: ]
2020/10/28 21:21:14 modules/task/task.go:51:handle() [E] Run task failed: error while loading reactions for pull # 42. Error: 403 Forbidden

[zeripath]

So now you need to look on your instance that you're migrating from as to what is special about the reactions on pull #42

That is by looking at /api/v1/repos/{owner}/{repo}/issues/{index}/reactions on the instance you're migrating from.

The error 403 is coming from there.

[zeripath]

I guess we should just probably not migrate the reactions if we get a 403 though - it's hardly a significant issue.

[zeripath]

Now the issue is why is the /api/v1/repos/{owner}/{repo}/issues/{index}/reactions causing a forbidden ?

[zeripath]

At least in master a Forbidden will predominantly come from:

    if !ctx.Repo.CanRead(models.UnitTypeIssues) {
        ctx.Error(http.StatusForbidden, "GetIssueReactions", errors.New("no permission to get reactions"))
        return
    }

Which could still be the case ... because this is a pull - and so the correct test is whether the ctx.Repo.CanRead(models.UnitTypePulls)

[zeripath]

13344 will also fix that.

[lakostin]

still error:
2020/10/29 10:50:37 ...ules/task/migrate.go:65:func1() [E] DeleteRepository: repository does not exist [id: 2, uid: 1, owner_name: , name: ]
2020/10/29 10:50:37 modules/task/task.go:51:handle() [E] Run task failed: error while listing reactions for comment 5961 in issue #40. Error: 403 Forbidden

there are no reactions though...

gitea=# select * from reaction where comment_id=5961;
id | type | issue_id | comment_id | user_id | created_unix | original_author_id | original_author
----+------+----------+------------+---------+--------------+--------------------+-----------------
(0 rows)

[zeripath]

OK #13344 fixed one issue - which has revealed another issue - I've just submitted a second PR to fix that.

The issue is not whether there are reactions or not - it's whether you would be allowed to read the issues or not.

If you gave the user on the gitea you were migrating from access to read issues this problem would go away.

If you were able to update the host gitea to have one of the backports - then similarly the problem would go away.

[lakostin]

OK #13344 fixed one issue - which has revealed another issue - I've just submitted a second PR to fix that.

Which number has the second PR?

The issue is not whether there are reactions or not - it's whether you would be allowed to read the issues or not.

If you gave the user on the gitea you were migrating from access to read issues this problem would go away.

I migrate repo with admin user.

If you were able to update the host gitea to have one of the backports - then similarly the problem would go away.

[6543]

@zeripath If I guess right the root of THIS specific issue is elsewhere (DB unique constrain) and cause by equal entrys ... caused by missing information on some reactions

If you give me some time I'll file a pull against - still do not have mouch time to write pulls

[zeripath]

@lakostin #13352

@6543 So if you look at the @lakostin 's log reports the issue is a 403 Forbidden. Looking at the API issue_reaction.go code the way that happens is if you fail the permissions test there - which precisely #13344 & #13349 both fix.

[zeripath]

There very well maybe another equal entries bug - but this report is simply the permissions problem.

[lakostin]

after #13352 all migrations completed successfully with pull requests. thank you!
project settings were not migrated, but im not sure if they should..

[6543]

@zeripath yes - to many open issues with similar look :O

@lakostin great to hear :) - and yes settings are not supposed to migrate