Description
A database schema mismatch was introduced in the 'default/policyadministration' service following a deployment of version v2.3.0, which enforced a 'strict' schema mode that the underlying database did not yet support. This incompatibility triggered 'PolicyDatabaseSchemaMismatchException' errors and 'relation does not exist' log entries, causing the service to fail health checks and return 500 errors for incoming requests. The impact extends to 9 entities, including 'default/policyadministration-5c94f76cbd-rfw2h' and 'default/policydecision', resulting in widespread service degradation. Remediation should focus on applying the required database migration '2025-12-15.2' before re-deploying the service.
Context
Database Schema Incompatibility
The service deployment enforced a strict schema mode requiring version '2025-12-15.2', but the database remained at '2025-12-15.1', causing the application to fail during startup and request processing.
Key Evidence:
[Event | Info] ConfigMap updated schema mode | First seen: 2026-05-27 22:31:09 | Count: 1
View detailsKubernetes event: ConfigMap updated {"resource":"configmap/policyadministration-config","namespace":"default","field":"POLICY_RULES_SCHEMA_MODE","new_value":"strict","note":"rollout_requires_migration_first"}[Event | Info] Deployment rollout v2.3.0 | First seen: 2026-05-27 22:31:12 | Count: 1
View detailsKubernetes event: Deployment rollout {"resource":"deployment/policyadministration","namespace":"default","image":"policyadministration:v2.3.0","strategy":"rollingUpdate","revision":"12"}[Log | Error] DB schema guard failed | First seen: 2026-05-27 22:32:10 | Count: 3
View detailsDB schema guard failed (code-level remediation: enforce schema compatibility on startup and rollback safely) {"request_id":"wl-req-1","caller":"storage/schema_guard.go:54","func":"CheckMinimumSchemaVersion","db":"postgres","expected_min_schema":"2025-12-15.2","actual_schema":"2025-12-15.1","action":"fail_fast_or_enter_readonly","deploy_order_hint":"apply_migration_before_rollout","service":"policyadministration"}[Exception] PolicyDatabaseSchemaMismatchException | First seen: 2026-05-27 22:32:19 | Count: 1
View detailsPolicyDatabaseSchemaMismatchException: expected policy_rules_v2 schema but DB is behind at repository.LoadPolicyRulesV2(repository/policy_store.go:143) at repository.LoadPolicyRulesV2(repository/policy_store.go:143) at repository.LoadPolicyRules(repository/policy_store.go:88) at service.RefreshPolicyCache(service/policy_cache.go:57) at http.Authorize(http/handlers/authorize.go:121) at http.Middleware.RequestID(http/middleware/request_id.go:33)
Impact
policydecision
policyadministration
policyenforcement
PolicyQueries
Suggested Remediation
Apply Database Migration and Revert Schema Mode
Consider applying the required database migration '2025-12-15.2' to your PostgreSQL instance to align the database schema with the expectations of the v2.3.0 deployment. Since the service is currently failing due to a 'strict' schema mode enforcement, you might want to temporarily revert the 'POLICY_RULES_SCHEMA_MODE' configuration to its previous value or a 'permissive' state if the migration cannot be applied immediately. This would allow the service to stabilize while you prepare the necessary database changes.
For Kubernetes environments, you could update the ConfigMap to disable the strict mode or point to the correct schema version. You might also consider using a Kubernetes Job to execute the migration script before the deployment rollout, ensuring the database is ready for the new application version.
apiVersion: v1
kind: ConfigMap
metadata:
name: policyadministration-config
namespace: default
data:
POLICY_RULES_SCHEMA_MODE: "permissive" # Revert to allow startup while migrating
Once the database migration is successfully applied, you could then update the ConfigMap to set the mode back to 'strict' and perform a rolling restart of the deployment to ensure the service correctly initializes with the updated schema.
Source: https://kubernetes.io/docs/concepts/configuration/configmap/