Oauth Schema Validation Failure

Chris
Chris
  • Updated
  • Jama Connect® version(s) - 9.35.x
    • Self-hosted
    • MSSQL 2022

Summary

During an installation or upgrade of v9.35.x, instances backed by a MSSQL database, admins may encounter an issue during oauth schema validation.

Error Upgrading - Oauth Schema Validation Failure - [authorization_entity_access_token]; found [nvarchar (Types#NVARCHAR)], but expecting [varchar(max)]

Resolution

After determining you are encountering this specific issue, the resolution will be to manually update the data type of a specific column and restart the affected oauth deployment.

Diagnosis

The first symptom will be the oauth pod failing to start due to a CrashLoopBackoff
You can check for this with kubectl get pods

Next check the available logging in the oauth  pod (and possibly the core-0 pod as well). You're looking for a stacktrace with the following information:
kubectl logs deploy/oauth
kubectl logs sts/core

[main] ERROR o.s.boot.SpringApplication - Application run failed
org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: 
[PersistenceUnit: default] Unable to build Hibernate SessionFactory; 
nested exception is org.hibernate.tool.schema.spi.SchemaManagementException: 
Schema-validation: wrong column type encountered in column [access_token_value] in table [authorization_entity_access_token]; 
found [nvarchar (Types#NVARCHAR)], but expecting [varchar(max) (Types#CLOB)]

Essentially, there is a conflict in the underlying definitions between Liquibase (responsible for creating the table definition) and Hibernate (which is validating the schema). 

In the affected database table (e.g. oauth.authorization_entity_access_token.access_token_value), alter the data type to match Hibernate's expected configuration:

ALTER TABLE authorization_entity_access_token ALTER COLUMN access_token_value VARCHAR(MAX);

Following the database change, restart the oauth deployment from the application server:

kubectl rollout restart deploy oauth

Additional Resources 

Feedback:
We welcome your input! Please sign in to leave any comments, suggestions, or ideas for improvement below.

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.