Error 500 creating a PR #16936

karthanistyr · 2021-09-02T22:58:15Z

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

Created a branch locally

git checkout -b upgrade/mybranch

Pushed branch to gitea

git push origin upgrade/mybranch

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.

The text was updated successfully, but these errors were encountered:

karthanistyr · 2021-09-02T23:00:53Z

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 · 2021-09-02T23:09:45Z

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 · 2021-09-02T23:10:46Z

I rolled back to 1.15.0 in the meantime.

karthanistyr · 2021-09-02T23:33:30Z

Flagging #16820 as potential culprit

zeripath · 2021-09-03T02:46:13Z

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 · 2021-09-03T02:48:34Z

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

RowanTaubitz · 2021-09-03T02:55:50Z

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

zeripath · 2021-09-03T03:39:46Z

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 · 2021-09-03T06:39:46Z

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 · 2021-09-03T06:55:26Z

The same problem

There is a flaw in go-gitea#16820 where it was missed that although xorm will not add a primary key to a table during syncing, it will remove an unique constraint. Users upgrading from 1.15.0 to 1.15.1 will therefore lose the unique constraint that makes this table work unless they run `gitea doctor recreate-table issue_index`. Postgres helpfully warns about this situation but MySQL does not. Main/1.16-dev is not affected by this issue as there is a migration that does the above recreation by default. Users moving directly to 1.15.1 from 1.14.x or lower are also not affected. Whilst we could force all users who ran 1.15.0 to do the above recreate-table call, this PR proposes an alternative: Just add the unique constraint back in for 1.15.x. This won't have any long term effects - just some wasted space for the unnecessary index. Fix go-gitea#16936 Signed-off-by: Andrew Thornton <art27@cantab.net>

zeripath · 2021-09-03T09:27:17Z

The same problem

gitea doctor recreate-table issue_index

There is a flaw in #16820 where it was missed that although xorm will not add a primary key to a table during syncing, it will remove an unique constraint. Users upgrading from 1.15.0 to 1.15.1 will therefore lose the unique constraint that makes this table work unless they run `gitea doctor recreate-table issue_index`. Postgres helpfully warns about this situation but MySQL does not. Main/1.16-dev is not affected by this issue as there is a migration that does the above recreation by default. Users moving directly to 1.15.1 from 1.14.x or lower are also not affected. Whilst we could force all users who ran 1.15.0 to do the above recreate-table call, this PR proposes an alternative: Just add the unique constraint back in for 1.15.x. This won't have any long term effects - just some wasted space for the unnecessary index. Fix #16936 Signed-off-by: Andrew Thornton <art27@cantab.net>

karthanistyr · 2021-09-03T11:53:16Z

Log of the above command after upgrading again back to 1.15.1:

bash-5.1$ gitea doctor recreate-table issue_index
2021/09/03 11:44:46 ...om/urfave/cli/app.go:405:RunAsSubcommand() [I] PING DATABASE postgres
2021/09/03 11:44:46 ...ations/migrations.go:444:func1() [I]
Recreating Table: issue_index for Bean: IssueIndex
2021/09/03 11:44:46 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table user Column max_repo_creation db default is
'-1', struct default is -1
2021/09/03 11:44:46 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table user Column keep_activity_private db default is , struct default is false
2021/09/03 11:44:46 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table user Column keep_activity_private db nullable is true, struct nullable is false
2021/09/03 11:44:46 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table repository Column original_service_type db default is 0, struct default is
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table comment has column old_assignee_id but struct has not related field
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table webhook Column is_system_webhook db default
is false, struct default is
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table webhook Column is_system_webhook db nullable is false, struct nullable is true
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table webhook Column http_method db default is 'POST', struct default is
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table email_address Column lower_email db nullable is true, struct nullable is false
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table external_login_user column avatar_url db type is TEXT, struct type is VARCHAR(255)
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table tracked_time Column time db nullable is true, struct nullable is false
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table review column type db type is VARCHAR(255),
struct type is INTEGER
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table project column board_type db type is INTEGER, struct type is BIGINT
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table project column type db type is INTEGER, struct type is BIGINT
2021/09/03 11:44:47 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table session has column created_unix but struct has not related field

Creating a PR after that worked on 1.15.1. Thanks and sorry I couldn't give you the table info sooner, I got to bed eventually 😪

Re:

Did you just run 1.15.0 without regenerating the dB?

Yes I had done that, simply rolled the container back to 1.15.0 without any further change. Hopefully I did not damage the schema. There is seldom any activity on this instance apart from me so I'm confident there hasn't been any more attempts to create issues and PRs before now.

viceice · 2021-09-03T12:18:22Z

Are the warnings normal? Should i do anything?

> gitea doctor recreate-table issue_index
2021/09/03 12:13:05 ...om/urfave/cli/app.go:405:RunAsSubcommand() [I] PING DATABASE postgres
2021/09/03 12:13:05 ...ations/migrations.go:444:func1() [I] Recreating Table: issue_index for Bean: IssueIndex
2021/09/03 12:13:06 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table user Column max_repo_creation db default is '-1', struct default is -1
2021/09/03 12:13:07 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table email_address Column lower_email db nullable is true, struct nullable is false
2021/09/03 12:13:07 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table external_login_user column avatar_url db type is TEXT, struct type is VARCHAR(255)
2021/09/03 12:13:08 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table project column board_type db type is INTEGER, struct type is BIGINT
2021/09/03 12:13:08 ...om/urfave/cli/app.go:405:RunAsSubcommand() [W] Table project column type db type is INTEGER, struct type is BIGINT

Using this as backend: PostgreSQL 11.13 on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
From Helm Chart: bitnami postgresql
Image currently pinned to

image:
  registry: gcr.io
  repository: bitnami-containers/postgresql
  tag: 11.13.0-debian-10-r7

zeripath · 2021-09-03T12:21:55Z

These are fine and can be ignored.

kenji21 · 2021-09-03T12:31:00Z

The same problem

gitea doctor recreate-table issue_index

same issue with a mysql (and same fix)

zeripath · 2021-09-04T17:00:11Z

Closing as fixed by #16938 and in 1.15.2

zeripath mentioned this issue Sep 3, 2021

Add unique constraint back into issue_index #16938

Merged

zeripath mentioned this issue Sep 3, 2021

New issue: generate issue index failed: get resource index failed #16941

Closed

6 tasks

zeripath mentioned this issue Sep 3, 2021

creating issue cause an error 500 #16814

Closed

6 tasks

lunny added the type/bug label Sep 3, 2021

zeripath closed this as completed Sep 4, 2021

zeripath linked a pull request Sep 4, 2021 that will close this issue

Add unique constraint back into issue_index #16938

Merged

zeripath added this to the 1.15.2 milestone Sep 4, 2021

go-gitea locked and limited conversation to collaborators Oct 19, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error 500 creating a PR #16936

Error 500 creating a PR #16936

karthanistyr commented Sep 2, 2021

karthanistyr commented Sep 2, 2021

karthanistyr commented Sep 2, 2021

karthanistyr commented Sep 2, 2021

karthanistyr commented Sep 2, 2021

zeripath commented Sep 3, 2021

zeripath commented Sep 3, 2021

RowanTaubitz commented Sep 3, 2021

zeripath commented Sep 3, 2021

zeripath commented Sep 3, 2021

NepPure commented Sep 3, 2021

zeripath commented Sep 3, 2021

karthanistyr commented Sep 3, 2021

viceice commented Sep 3, 2021

zeripath commented Sep 3, 2021

kenji21 commented Sep 3, 2021

zeripath commented Sep 4, 2021 •

edited

Loading

Error 500 creating a PR #16936

Error 500 creating a PR #16936

Comments

karthanistyr commented Sep 2, 2021

Description

karthanistyr commented Sep 2, 2021

karthanistyr commented Sep 2, 2021

karthanistyr commented Sep 2, 2021

karthanistyr commented Sep 2, 2021

zeripath commented Sep 3, 2021

zeripath commented Sep 3, 2021

RowanTaubitz commented Sep 3, 2021

zeripath commented Sep 3, 2021

zeripath commented Sep 3, 2021

NepPure commented Sep 3, 2021

zeripath commented Sep 3, 2021

karthanistyr commented Sep 3, 2021

viceice commented Sep 3, 2021

zeripath commented Sep 3, 2021

kenji21 commented Sep 3, 2021

zeripath commented Sep 4, 2021 • edited Loading

zeripath commented Sep 4, 2021 •

edited

Loading