ERROR: column "grant_type_device_code" does not exist at character

[beposec]

The latest "main" from tonight is not allowing authentication with OIDC.

MAS Errors:

root-mas-1 | 2024-02-03T06:42:01.084858Z ERROR http.server.request{otel.kind="server" otel.name="POST /oauth2/introspect" network.protocol.name="http" network.protocol.version="1.1" http.method="POST" url.path="/oauth2/introspect" url.scheme="http" http.route="/oauth2/introspect" user_agent.original="Synapse/1.100.0"}:handlers.oauth2.introspection.post{client.id="XXXXXXXXXXXXXXXXX"}:db.oauth2_client.lookup{oauth2_client.id=XXXXXXXXXXXXXXXXX db.statement="\n SELECT oauth2_client_id\n , encrypted_client_secret\n , application_type\n , redirect_uris\n , grant_type_authorization_code\n , grant_type_refresh_token\n , grant_type_client_credentials\n , grant_type_device_code\n , contacts\n , client_name\n , logo_uri\n , client_uri\n , policy_uri\n , tos_uri\n , jwks_uri\n , jwks\n , id_token_signed_response_alg\n , userinfo_signed_response_alg\n , token_endpoint_auth_method\n , token_endpoint_auth_signing_alg\n , initiate_login_uri\n FROM oauth2_clients c\n\n WHERE oauth2_client_id = $1\n "}: mas_storage_pg::oauth2::client: error=error returned from database: column "grant_type_device_code" does not exist root-mas-1 | thread 'tokio-runtime-worker' panicked at /app/crates/handlers/src/oauth2/introspection.rs:188:10: root-mas-1 | called Result::unwrap()on anErr value: RepositoryError { source: Driver { source: Database(PgDatabaseError { severity: Error, code: "42703", message: "column \"grant_type_device_code\" does not exist", detail: None, hint: None, position: Some(Original(343)), where: None, schema: None, table: None, column: None, data_type: None, constraint: None, file: Some("parse_relation.c"), line: Some(3713), routine: Some("errorMissingColumn") }) } } root-mas-1 | 2024-02-03T06:42:01.085242Z ERROR mas_listener::server: Join error: task 2175 panicked root-mas-1 | 2024-02-03T06:42:04.926925Z ERROR mas_listener::server: Error while serving connection: error shutting down connection: Socket not connected (os error 107) root-mas-1 | 2024-02-03T06:42:04.927023Z ERROR mas_listener::server: Error while serving connection: error shutting down connection: Socket not connected (os error 107)

MAS-DB Errors:
root-mas-db-1 | 2024-02-03 06:37:20.129 UTC [36] ERROR: column "grant_type_device_code" does not exist at character 343 root-mas-db-1 | 2024-02-03 06:37:20.129 UTC [36] STATEMENT: root-mas-db-1 | SELECT oauth2_client_id root-mas-db-1 | , encrypted_client_secret root-mas-db-1 | , application_type root-mas-db-1 | , redirect_uris root-mas-db-1 | , grant_type_authorization_code root-mas-db-1 | , grant_type_refresh_token root-mas-db-1 | , grant_type_client_credentials root-mas-db-1 | , grant_type_device_code root-mas-db-1 | , contacts root-mas-db-1 | , client_name root-mas-db-1 | , logo_uri root-mas-db-1 | , client_uri root-mas-db-1 | , policy_uri root-mas-db-1 | , tos_uri root-mas-db-1 | , jwks_uri root-mas-db-1 | , jwks root-mas-db-1 | , id_token_signed_response_alg root-mas-db-1 | , userinfo_signed_response_alg root-mas-db-1 | , token_endpoint_auth_method root-mas-db-1 | , token_endpoint_auth_signing_alg root-mas-db-1 | , initiate_login_uri root-mas-db-1 | FROM oauth2_clients c root-mas-db-1 | root-mas-db-1 | WHERE oauth2_client_id = $1

[sandhose]

Migrations do not run automatically, and you should apply them every time you upgrade versions.

To do so, you'd run mas-cli database migrate, or start the server with mas-cli server --migrate which will automatically applies the migrations and start the server

[beposec]

Thanks a lot for your help, again :-) This seems to help. Shouldn't the migration run automatically to provide automatic docker container updates?

[sandhose]

There is already a way to do that, which is the --migrate option on the mas-cli server command. I guess this could be the default? I'm not yet sure how I feel about automatically applying migrations

[beposec]

It is certainly always difficult to weigh up problems with upgrades or vulnerabilities due to unpatched software.
Doesn't most software do automatic database migrations during upgrades?

[sandhose]

Migrations now run automatically on startup, which means this kind of issues shouldn't happen anymore

[beposec]

@sandhose thanks a lot! Great change for running automated service upgrades!