DB Migrations might not be running

[Laikar]

Not really sure if this issue is relevant on this project or on seafile upstream, I will report on both, https://github.com/haiwen/seahub/issues/6550

I activated CLIENT_SSO_VIA_LOCAL_BROWSER = True To login with system browser in seafile clients, but when enabled, clients fail to get sso url, and on server logs the following message appears

seahub-1          | 2024-08-13 14:21:26,656 [ERROR] seahub.api2.endpoints.sso.client_sso_link:54 post (1146, "Table 'seahub_db.base_clientssotoken' doesn't exist")
seahub-1          | 2024-08-13 14:21:26,657 [ERROR] django.request:241 log_response Internal Server Error: /api2/client-sso-link/

Looking through the Seafile sources, that table is created in the v11.0.0 db migrations script or what i guess is the initial DB setup. The original problem was fixed by manually crating the DB using the v11.0.0 migration script linked above.

I've been running this deployment since version 9, so my only guess is that migrations aren't running for whatever reason, I will backup the DB and try to run migrations on a separate testing environment and report what I find.

[ggogel]

Hi, thank you for the issue report.

Upon investigating, I believe this might be an upstream issue. Here's a summary of what I found:

Firstly, I reviewed my production database and observed that some of the migrations are indeed missing. Upon checking the commit history of the SQL migration script for 11.0, it appears that changes were introduced after the initial release of version 11.0.0. Notably, the last update to this file occurred in version 11.0.4.

The issue seems to stem from the fact that this script, which executes the SQL migrations, is only triggered during the upgrade from 10.0.x to 11.0.y. If your upgrade path involved updating to 11.0 before the release of 11.0.4, your database would likely be missing these migrations.

In this deployment, the update scripts are executed within seafile-server. This can be a bit confusing, as some files, although managed in the seahub repository, are actually utilized exclusively by seafile-server.

[ggogel]

I set up a new local deployment with version 10.0.1 and then upgraded to version 11.0.12. During the migration process, the table base_clientlogintoken was successfully created.

The migration script did generate a single warning though:

seafile-server-1  | [WARNING] Failed to execute sql: (1054, "Unknown column 'domain' in 'org_saml_config'")

Despite this warning, I confirmed that the script executed the remaining lines.

This test supports my assumption that the upgrade path is indeed the cause of the problem.

Additionally, I updated the upgrade.py script to the latest version from the seafile-docker repository to ensure full compatibility with the upgrade logic. However, this did not affect the outcome of the test.

[ggogel]

If you upgraded from 10.0.x to a version of 11 prior to 11.0.4, and are encountering issues, here’s a workaround you can try. Please ensure you take a full backup of your data before proceeding.

To apply the workaround, follow these steps:

1. Start a bash shell inside your seafile-server container.
2. Run the following command to reset the version indicator:

   echo "10.0.1" > shared/seafile/seafile-data/current_version

3. After executing the command, restart your seafile-docker container.

This process should trigger the upgrade script to rerun, including the necessary migrations.