Migration fails on retry because of duplicate issues (Postgres) #12351

New Issue

GiteaMirror · 2025-11-02T10:06:41-06:00

GiteaMirror commented

2025-11-02 10:06:41 -06:00

Originally created by @TristanWasTaken on GitHub (Jan 18, 2024).

Description

I've had this issue after my issue explained at #28846
If the migration fails after already having started (in my case not yet finished) to migrate the issues from https://github.com/tachiyomiorg/tachiyomi and you click the retry button, it fails on Postgres with the issue pq: duplicate key value violates unique constraint "UQE_release_n"

How I fixed it:

Look in the repository table or the task table what the repository id is.
Go to the issue table and delete the issues with that repository id.
Click retry button.
It works as intended

it's probably the same on MySQL (looking at you #28846), but I didn't test it and I don't really want to do this another time since the average full migration time of that repo with all options is ~8h and more

The migration is still ongoing on the Gitea demo site: https://try.gitea.io/TristanWasTaken/tachiyomi
It'll take ~8h to do a full migration. Or at least that's how long it took on my instance.

Gitea Version

1.21.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

Git Version

No response

Operating System

No response

How are you running Gitea?

docker gitea/gitea:1.21.3 image, with postgres and redis
Please note that I also tried with memory instead of redis

Database

PostgreSQL

Originally created by @TristanWasTaken on GitHub (Jan 18, 2024). ### Description I've had this issue after my issue explained at #28846 If the migration fails after already having started (in my case not yet finished) to migrate the issues from https://github.com/tachiyomiorg/tachiyomi and you click the retry button, it fails on Postgres with the issue `pq: duplicate key value violates unique constraint "UQE_release_n"` How I fixed it: 1. Look in the `repository` table or the `task` table what the repository id is. 2. Go to the `issue` table and delete the issues with that repository id. 3. Click retry button. 4. It works as intended it's probably the same on MySQL (looking at you #28846), but I didn't test it and I don't really want to do this another time since the average full migration time of that repo with all options is ~8h and more The migration is still ongoing on the Gitea demo site: https://try.gitea.io/TristanWasTaken/tachiyomi It'll take ~8h to do a full migration. Or at least that's how long it took on my instance. ### Gitea Version 1.21.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ![gitea_duplicate_issues](https://github.com/go-gitea/gitea/assets/43283797/e8372050-862d-4452-91da-493f3d16f842) ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? docker `gitea/gitea:1.21.3` image, with `postgres` and `redis` Please note that I also tried with `memory` instead of redis ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 10:06:41 -06:00

GiteaMirror commented

2025-11-02 10:06:41 -06:00

@lunny commented on GitHub (Jan 19, 2024):

Caused by #26228, @kerwin612

@lunny commented on GitHub (Jan 19, 2024): Caused by #26228, @kerwin612

GiteaMirror commented

2025-11-02 10:06:42 -06:00

@mamatjasec commented on GitHub (Mar 4, 2024):

We are having the same issue on our instance after upgrading from 1.15.x to 1.24.x and then to 1.25.x
In this hindsight Gitea started to behave very unpredictable.
For instance, the heatmap is not working, the tags and branches on the web interface do not show correct data.
Manually running gitea admin repo-sync-releases results in
2024/03/04 14:13:45 cmd/admin.go:393:runRepoSyncReleases() [W] SyncReleasesWithTags: unable to PushUpdateAddTag: "XXXX" to Repo[109:XXX/YYYY]: InsertOne: pq: duplicate key value violates unique constraint "UQE_release_n"
Gitea doctor:


[1] Check Database Version
 - [I] Expected database version: 280
OK

All done (checks: 1).

gitea doctor check --run hooks

[1] Check if hook files are up-to-date and executable
OK

All done (checks: 1).
gitea doctor check --run check-commit-graphs

[1] Check commit-graphs
 - [I] Checked 109 repositories, 1 without commit-graphs.
OK

All done (checks: 1).
gitea doctor check --run check-db-consistency

[1] Check consistency of database
 - [W] Found 2 Orphaned OAuth2Application without existing User
OK

All done (checks: 1).

@lunny you mentioned the cause, but is there any remedy we can do in the meantime with the gitea doctor?

@mamatjasec commented on GitHub (Mar 4, 2024): We are having the same issue on our instance after upgrading from 1.15.x to 1.24.x and then to 1.25.x In this hindsight Gitea started to behave very unpredictable. For instance, the heatmap is not working, the tags and branches on the web interface do not show correct data. Manually running `gitea admin repo-sync-releases` results in `2024/03/04 14:13:45 cmd/admin.go:393:runRepoSyncReleases() [W] SyncReleasesWithTags: unable to PushUpdateAddTag: "XXXX" to Repo[109:XXX/YYYY]: InsertOne: pq: duplicate key value violates unique constraint "UQE_release_n" ` Gitea doctor: ``` gitea doctor check --run check-db-version [1] Check Database Version - [I] Expected database version: 280 OK All done (checks: 1). gitea doctor check --run hooks [1] Check if hook files are up-to-date and executable OK All done (checks: 1). gitea doctor check --run check-commit-graphs [1] Check commit-graphs - [I] Checked 109 repositories, 1 without commit-graphs. OK All done (checks: 1). gitea doctor check --run check-db-consistency [1] Check consistency of database - [W] Found 2 Orphaned OAuth2Application without existing User OK All done (checks: 1). ``` @lunny you mentioned the cause, but is there any remedy we can do in the meantime with the gitea doctor?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12351