Helm chart cannot configure database.operation, making v0.48.0 undeployable via the chart

[UdeshAthukorala]

Description

As of v0.48.0, ThunderID fails to start unless database.operation is configured. The Helm chart has no way to express that key: configuration.database renders only config, runtime, and user, and the chart's conf/deployment.yaml templates each database block explicitly rather than serialising the map. As a result, --set configuration.database.operation.* is silently accepted by Helm and then discarded, and there is no values path that produces a valid v0.48.0 configuration.

This appears to make v0.48.0 undeployable via the official Helm chart.

The shipped ZIP/binary packs are unaffected — their bundled deployment.yaml has always defined database.operation. Only chart-based (Kubernetes) deployments and any deployment supplying its own deployment.yaml are impacted.

Why v0.48.0 needs the operation database

operationdb's schema (dbscripts/operationdb/postgres.sql) carries the tables behind two v0.48.0 changes:

• SSO_SESSION, SSO_SESSION_CONTEXT, SSO_SESSION_PARTICIPANT — flow-centric browser SSO (Add flow-centric browser SSO #3779)
• REVOKED_TOKEN — token revocation, which now defaults to enabled: true / source: "db" in default.json

The SSO session service initialises unconditionally during startup, so a missing database.operation is fatal rather than degrading.

Steps to reproduce

1. The chart cannot render the key

git archive v0.48.0 install/helm | tar -x -C /tmp/chart
cd /tmp/chart/install/helm
helm template t . \
  --set configuration.database.operation.type=postgres \
  --set configuration.database.operation.postgres.name=operationdb \
  --set configuration.database.operation.postgres.hostname=pg.example.com \
  --set configuration.database.operation.postgres.port=5432 \
  | grep -i operation

Exit code 0, no output. The rendered thunderid-config-map / deployment.yaml contains:

database keys rendered: ['config', 'runtime', 'user']

The override is dropped without warning.

2. The resulting configuration is fatal at startup

Using a deployment.yaml that defines only config, runtime, and user (equivalent to what the chart renders):

level=ERROR msg="Failed to initialize SSO session service"
  error="failed to get runtime DB transactioner for the SSO session service:
         failed to get operation database client: database type is not configured"
❌ Bootstrap failed.

The process exits and never binds its port. The same config on v0.47.0 starts normally and reports readiness 200 — the only variable changed is the version.

Expected behaviour

configuration.database.operation is configurable through the chart and rendered into deployment.yaml, so a chart-based v0.48.0 deployment starts.

Actual behaviour

The key does not exist in the chart. helm template/helm install succeed and produce a configuration the server rejects at startup.

Suggested fix

1. Add an operation block to install/helm/values.yaml under configuration.database, mirroring config/runtime/user.
2. Render it in install/helm/conf/deployment.yaml alongside the existing database blocks.
3. Include operation in the $usingSqlite check in templates/thunderid-deployment.yaml, which currently inspects only config, runtime, user, and consent.
4. Consider failing fast with a clear message when a required database is unset, rather than allowing a render that cannot start.

Additional context

Two documentation gaps worth addressing alongside this:

• The v0.48.0 release notes' breaking-changes section does not mention the new database.operation requirement. It arrived via the SSO feature (Add flow-centric browser SSO #3779) rather than a change flagged as breaking, so upgraders configuring their own deployment.yaml hit a hard startup failure with no migration note.
• Deployments that provision databases from dbscripts/ need to create operationdb and load dbscripts/operationdb/postgres.sql; a migration note covering both the config key and the schema would help.

Version

v0.48.0 (compared against v0.47.0). Chart inspected and rendered at tag v0.48.0; startup behaviour reproduced with the macos-arm64 pack.