Migration from 1.15 to 1.16 fails on webauthn table #8550

New Issue

2025-11-02T08:10:31-06:00

GiteaMirror commented

2025-11-02 08:10:31 -06:00

Originally created by @ashimokawa on GitHub (Feb 11, 2022).

Gitea Version

1.16.1

Git Version

2.30.2

Operating System

Debian 11

How are you running Gitea?

Self-compiled from https://codeberg.org/Codeberg/gitea/src/branch/codeberg-1.16

Database

MySQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

When doing a test migration for coderberg.org to 1.16 in an isolated vm, the migration fails with

022/02/11 13:34:47 ...ations/migrations.go:465:Migrate() [I] Migration[207]: Add webauthn table and migrate u2f data to webauthn
2022/02/11 13:34:47 routers/common/db.go:33:InitDBEngine() [E] ORM engine initialization attempt #1/10 failed. Error: migrate: migration[207]: Add webauthn table and migrate u2f data to webauthn failed: Error 1406: Data too long for column 'credential_id' at row 1

The credential_id is a varchar(255) column.
Relaxing the sql mode would probably work but truncate the data, probably leading to u2f failing for affected users

(Might be related to #18477)

Screenshots

No response

Originally created by @ashimokawa on GitHub (Feb 11, 2022). ### Gitea Version 1.16.1 ### Git Version 2.30.2 ### Operating System Debian 11 ### How are you running Gitea? Self-compiled from https://codeberg.org/Codeberg/gitea/src/branch/codeberg-1.16 ### Database MySQL ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Description When doing a test migration for coderberg.org to 1.16 in an isolated vm, the migration fails with ``` 022/02/11 13:34:47 ...ations/migrations.go:465:Migrate() [I] Migration[207]: Add webauthn table and migrate u2f data to webauthn 2022/02/11 13:34:47 routers/common/db.go:33:InitDBEngine() [E] ORM engine initialization attempt #1/10 failed. Error: migrate: migration[207]: Add webauthn table and migrate u2f data to webauthn failed: Error 1406: Data too long for column 'credential_id' at row 1 ``` The credential_id is a varchar(255) column. Relaxing the sql mode would probably work but truncate the data, probably leading to u2f failing for affected users (Might be related to #18477) ### Screenshots _No response_

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

GiteaMirror closed this issue

2025-11-02 08:10:32 -06:00

GiteaMirror commented

2025-11-02 08:10:32 -06:00

@zeripath commented on GitHub (Feb 11, 2022):

Duplicate #18477

@zeripath commented on GitHub (Feb 11, 2022): Duplicate #18477

GiteaMirror commented

2025-11-02 08:10:33 -06:00

@ashimokawa commented on GitHub (Feb 11, 2022):

@zeripath

How is this a duplicate? This is a bug report about a failed database migration.

@ashimokawa commented on GitHub (Feb 11, 2022): @zeripath How is this a duplicate? This is a bug report about a failed database migration.

GiteaMirror commented

2025-11-02 08:10:33 -06:00

@zeripath commented on GitHub (Feb 11, 2022):

Sorry I apologise I misread your message.

What db are you using?

@zeripath commented on GitHub (Feb 11, 2022): Sorry I apologise I misread your message. What db are you using?

GiteaMirror commented

2025-11-02 08:10:33 -06:00

@ashimokawa commented on GitHub (Feb 11, 2022):

@zeripath

mariadb 10.5 is the database.
The column credential_id in the newly created webauthn table is created as a varchar(255) column which is obviously too small for what is being migrated from the u2f table, so the migration fails.

The migration would probably "work" if chosing another sql_mode which allows just overflowing columns to be truncated - which then would break webauthn for affected users. That's why I pointed to the other issue which might be related - a seemingly okay migration with truncation.

@ashimokawa commented on GitHub (Feb 11, 2022): @zeripath mariadb 10.5 is the database. The column credential_id in the newly created webauthn table is created as a varchar(255) column which is obviously too small for what is being migrated from the u2f table, so the migration fails. The migration would probably "work" if chosing another sql_mode which allows just overflowing columns to be truncated - which then would break webauthn for affected users. That's why I pointed to the other issue which might be related - a seemingly okay migration with truncation.

GiteaMirror commented

2025-11-02 08:10:33 -06:00

@fnetX commented on GitHub (Feb 12, 2022):

@christiaangoossens You mean after updating to Gitea 1.16.1 or specifically to the mentioned PR? If the former, this is unlikely related to this issue, please check the other open issues or create a new one. Or check the configuration and changelog about breaking changes.

@fnetX commented on GitHub (Feb 12, 2022): @christiaangoossens You mean after updating to Gitea 1.16.1 or specifically to the mentioned PR? If the former, this is unlikely related to this issue, please check the other open issues or create a new one. Or check the configuration and changelog about breaking changes.

GiteaMirror commented

2025-11-02 08:10:34 -06:00

@christiaangoossens commented on GitHub (Feb 12, 2022):

@fnetX My issue seemed to be related due to the very similar scenario and that I saw that same migration error happen, but as it's solved and probably had more to do with my outdated config, I have removed the comment. Thanks for your comment!

@christiaangoossens commented on GitHub (Feb 12, 2022): @fnetX My issue seemed to be related due to the very similar scenario and that I saw that same migration error happen, but as it's solved and probably had more to do with my outdated config, I have removed the comment. Thanks for your comment!

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#8550