The catalogue pinned gitea 1.22.6. The machine being migrated runs 1.27.3. Gitea migrates its database forward on startup and will not run against a schema a newer version wrote, so the cutover failed: the restored database came up, the module's container started, found the schema too new, and exited. The predecessor was started again from its own database and the forge was down for about three minutes.
1.27.4 does not exist yet — 1.27.3 is the newest release — so this pins exactly what is running. Same version is also the better cutover: a data move with no schema migration in the same window.
A downgrade is never safe for a service that migrates its own schema, and nothing in the mesh checks the direction today. That is worth its own issue, since it applies to every module whose catalogue pin is older than what a machine runs, not only this one.
The catalogue pinned gitea **1.22.6**. The machine being migrated runs **1.27.3**. Gitea migrates its database forward on startup and will not run against a schema a newer version wrote, so the cutover failed: the restored database came up, the module's container started, found the schema too new, and exited. The predecessor was started again from its own database and the forge was down for about three minutes.
1.27.4 does not exist yet — 1.27.3 is the newest release — so this pins exactly what is running. Same version is also the better cutover: a data move with no schema migration in the same window.
A downgrade is never safe for a service that migrates its own schema, and nothing in the mesh checks the direction today. That is worth its own issue, since it applies to every module whose catalogue pin is older than what a machine runs, not only this one.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The catalogue pinned gitea 1.22.6. The machine being migrated runs 1.27.3. Gitea migrates its database forward on startup and will not run against a schema a newer version wrote, so the cutover failed: the restored database came up, the module's container started, found the schema too new, and exited. The predecessor was started again from its own database and the forge was down for about three minutes.
1.27.4 does not exist yet — 1.27.3 is the newest release — so this pins exactly what is running. Same version is also the better cutover: a data move with no schema migration in the same window.
A downgrade is never safe for a service that migrates its own schema, and nothing in the mesh checks the direction today. That is worth its own issue, since it applies to every module whose catalogue pin is older than what a machine runs, not only this one.