Users become "Ghost" when restoring from dump

[DuckDuckWhale]

• Gitea version (or commit ref): 1.13.0
• Git version: 2.25.1
• Operating system: Ubuntu Server 20.04 LTS
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • N/A
• Log gist: N/A

Description

Found this when testing a periodic backup. Seems that the culprit is that the last column (keep_activity_private) becomes NULL for some users in this NOT NULL column after upgrading to Gitea 1.13.0 from 1.12.5, which causes the exported .sql file to be rejected by postgresql and Gitea to display "Ghost" for those users.

[DuckDuckWhale]

Migrations seems to be there in #11353... Did it not work?

[zeripath]

Sorry did you restore the dump from 1.12.5 directly into 1.13? I think the issue is that dumps from 1.12.x never stored the version table. This should now be fixed on 1.13

[DuckDuckWhale]

No. I dumped and restored after upgrading to 1.13.0 from 1.12.5.

[lafriks]

As not all users was imported that's why Ghost is displayed. Does original table has those values null?

[DuckDuckWhale]

Yeah. Not sure why that's the case since the migration should have taken care of it. Thought it might be a bug so reported it here.

[commel]

I hit that bug as well. Migrated from 1.13.1 from MariaDB 10.0.38 with "gitea dump -c postgres" to insert into PostgreSQL 11.

FEHLER: NULL-Wert in Spalte »keep_activity_private« verletzt Not-Null-Constraint

[vosdev]

All my users are also broken after a restore. All user entries fail importing into postgres with the following error:

ERROR:  null value in column "keep_activity_private" violates not-null constraint
DETAIL:  Failing row contains (7, galaxy, galaxy, , , f, , , , f, 0, 0, , 1, , , lSMiE8D7ei, ulnAng3IHw, , , 1601903326, 1601904018, 0, f, -1, t, f, f, f, f, f, f, 1a18fd989ddbc0dbb8d2ddfdf6fa075e, , t, 0, 0, 0, 8, 1, 1, 0, t, , gitea, null).

Dumping and restoring from and to a Gitea 1.13.1 docker image with postgres 11.6

[6543]

I found a migration issue ...

-> #14387

I think this is related to this issue ..., to repair you manually have to alter the SQL dump who create the User Table to not have a NOT NULL DEFAULT false constrain. after restore use the ./gitea doctor recreate-table user to fix it ...

[6543]

@DuckDuckWhale thanks for reporting, @vosdev did manually altering the user table schema fix it?

[commel]

@DuckDuckWhale thanks for reporting, @vosdev did manually altering the user table schema fix it?

It did for me. Also if the number of users if small, manually adjusting the SQL works as well. But great to see the fix incoming! :-)

[vosdev]

@DuckDuckWhale thanks for reporting, @vosdev did manually altering the user table schema fix it?

I did not try but it seems @commel has been succesful.

I automate a daily restore of the latest backup zipfile to test if it actually works because I do not want to be surprised with errors when I actually need to restore from backup :-)