Error 500 creating a PR

[karthanistyr]

• Gitea version (or commit ref): v1.15.1 (docker image from docker hub)
• Git version: N/A
• Operating system: debian 10
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
• Log :

2021/09/02 22:52:16 ...ervices/pull/pull.go:39:NewPullRequest() [I] [SQL] BEGIN TRANSACTION [] - 355.924µs
2021/09/02 22:52:16 models/index.go:92:getNextResourceIndex() [I] [SQL] SELECT max_index FROM issue_index WHERE
group_id = $1 [1] - 485.227µs
2021/09/02 22:52:16 models/index.go:66:GetNextResourceIndex() [I] [SQL] INSERT INTO issue_index (group_id, max_index) VALUES ($1,1) ON CONFLICT (group_id) DO UPDATE SET max_index = issue_index.max_index+1 [1] - 551.813µs
2021/09/02 22:52:16 models/pull.go:431:NewPullRequest() [I] [SQL] ROLLBACK [] - 107.085µs
2021/09/02 22:52:16 ...ers/web/repo/pull.go:1113:CompareAndPullRequestPost() [E] NewPullRequest: generate issue
index failed: pq: there is no unique or exclusion constraint matching the ON CONFLICT specification

Description

1. Created a branch locally

git checkout -b upgrade/mybranch

2. Pushed branch to gitea

git push origin upgrade/mybranch

3. On Gitea web app: create PR; error 500 occurs when committing the PR (clicking "Create Pull Request" button)

On a gitea running in docker; 1.15.0 used to work fine, but v1.15.1 does not.

[karthanistyr]

Note on my upgrade process (as per https://docs.gitea.io/en-us/install-with-docker/#upgrading)

docker-compose down
# gitea stop...
# upgrading the gitea version number in compose file
docker-compose pull
docker-compose up -d

[karthanistyr]

Maybe it looks like a db migration issue, as the specific migration script (models/migrations/v182.go) was amended, but my db may have had run it already, and so maybe is missing stuff? Just speculating here...

[karthanistyr]

I rolled back to 1.15.0 in the meantime.

[karthanistyr]

Flagging #16820 as potential culprit

[zeripath]

Seriously postgres? There's a primary key - that's an unique constraint!

I don't understand why our integration tests didn't catch this. So I think we need a small simple test that is going to replicate the issue.

It would be helpful to know what version of pq you're running.

When you say rolled back what do you mean? Did you just run 1.15.0 without regenerating the dB? If so you may be able to now drop in 1.15.1 and the unique constraint will be kept.

To that end it would be helpful to see what the current schema of the issue_index table is.

[zeripath]

Similarly what happens if you run gitea doctor recreate-table issue_index on 1.15.1?

[RowanTaubitz]

Just ran into this issue as well, running gitea doctor recreate-table issue_index fixed it for us - thanks!

[zeripath]

Hmm this implies that xorm is dropping the unique constraint and not adding in the primary key one. It may be that we need to add the (unnecessary) unique constraint back in here and let that be removed in 1.16 when we regenerate the table.

This doubly raises the importance of telling us the schema of the table.

[zeripath]

OK I've just looked at this table now I'm actually up and out of bed.

Unfortunately I think all users upgrading from 1.15.0 to 1.15.1 need to run gitea doctor recreate-table issue_index - it's just that postgres is the only one telling us this.

Damn. I totally forgot that Xorm would drop the Unique constraint - (I knew it wouldn't create the PK). If I'd just left the unique constraint in this would have been fine.

[NepPure]

The same problem

[zeripath]

The same problem

gitea doctor recreate-table issue_index