gogs/gogs

Error 1062 (23000): Duplicate entry '' for key 'access_token.sha256'

axiomen opened this issue · 2 comments

axiomen commented

Gogs version

0.13.0

Git version

  • Server: 2.39.3
  • Client: N/A

Operating system

RedHat 9

Database

MySQL 8.0.36

Describe the bug

I'm in the process of migrating Gogs 0.12.3 (on CentOS7) to another machine to Gogs 0.13.0 (on RedHat 9). I backed up Gogs 0.12.3 with adjusted 0.13.0 app.ini, moved it to the new machine, but when trying to restore the backup, I'm met with this database error Duplicate entry '' for key 'access_token.sha256'. I checked the database on both sides, and I cannot find the duplicate anywhere. I tried to manually remove it from the table, but I'm met with the same error upon restoring. Both installations are on the same MySQL version.

Might be worth mentioning that 0.12.3 on the first machine was installed from Packager.io, while the new 0.13.0 version on the other machine was installed from binary.

To reproduce

  1. Adjust app.ini to match the new 0.13.0 config.
  2. Create a backup on machine one running 0.12.3 with ./gogs backup --exclude-repos
  3. Move the backup to machine two running 0.13.0 and attempt a restore with ./gogs restore --from="backup.zip"
  4. Shortly after the process starts, receive error Duplicate entry '' for key 'access_token.sha256'.

Expected behavior

Successful restore from one machine to the other.

Additional context

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
unknwon commented

Hey,

I think it because the backed-up data did not get chance to run the require DB migration that makes sure every row has a non-empty value for the access_tokens.sha256 column:

gogs/internal/database/migrations/migrations.go

Lines 55 to 56 in dd49412

// v19 -> v20:v0.13.0
NewMigration("migrate access tokens to store SHA56", migrateAccessTokenToSHA256),

There are two possible approaches:

  1. Run the 0.13.0 version against the database on your old machine once, so it can complete the DB migration. Then backup again and restore.
  2. Connect to the database on the new machine, and drop the unique constraint on the access_tokens.sha256 column, restore your backup, run 0.13.0 (which will add back the unique constraint as part of DB migration).

Be noted that approach 2 only solves this specific error you're getting blocked (which, maybe the only one after all, or you may also hit #7687).

axiomen commented

I'll see if I can go with the first option. It's a production machine, so I wanted to avoid dealing with the update on it, as we need to move to the new machine anyway.

About #7687, since we use LDAP for logging in, with a few native Gogs accounts, does that mean I would have to go through every non-LDAP account, login without a password and set it up again?