2026-08-25 · run 2026-08-25-26.0.0-to-26.7.1-1

26.0.0 → 26.7.1

Environment

Identical to 2026-08-25-25.0.6-to-26.0.0-1 (same box, same fixture, same container) except:

Caveat on comparability: this realm reached 26.0.0 by migration, not by a clean 26.0.0 install. A realm that was born at 26.0.0 may migrate differently. Stated because our fixture-comparability rule makes differently-shaped fixtures non-aggregatable, and this is a shape difference.

Procedure

./bin/snapshot.sh baseline-26.0.0-typical-1k
./bin/upgrade.sh 26.7.1

Timings

Outcome

• Reached ready
• Realm config intact — 1000 users
• Login flow works — labuser7 token issued
• Custom SPI / themes / federation — not in fixture

Breakage observed

Schema migration ran AFTER the server reported "started"

• Symptom: Quarkus logged started in 3.029s. Listening on: http://0.0.0.0:8080 at 15:32:28,510 — then Updating database began at 15:32:29,111 on executor-thread-1, finishing ~15:32:32,4. On the 25.0.6 → 26.0.0 run the same work ran on (main) before ready.
• Evidence: container log, both runs, timestamps above.
• Cause: suspected, NOT confirmed. Two candidate explanations and this run cannot distinguish them: (a) 26.7.x defers schema migration out of the startup path, or (b) migration is lazily triggered by the first inbound request, and the trigger here was wait-ready.sh polling the token endpoint. The executor-thread-1 context is consistent with (b).
• Fix or workaround: none — behaviour, not a fault.
• Would this hit a customer? Potentially serious if (a) holds. A server that reports started and opens its port while the schema is still migrating will pass a naive TCP or /health/started check, so a load balancer or Kubernetes readiness probe could route production traffic mid-migration. That is precisely the Infinispan/rolling-update failure class the ledger already lists.
• RESOLVED 2026-08-25 by 2026-08-25-26.0.0-to-26.7.1-2: explanation (a) holds — migration runs unprompted, confirmed from Postgres with the server left untouched for 120s. But the consequence stated here was wrong: /health/ready correctly reports 503 throughout, so a readiness probe is safe. The exposure is /health/started and TCP port checks. See that record.
• NEXT ACTION — this is the highest-value follow-up from today. Re-run with no client polling at all, watching the log passively, to establish which explanation holds. It is cheap, and if (a) is true it is publishable ledger content that nobody else has measured.

Hostname v1 warning changed emission path between 26.0.0 and 26.7.1

• Symptom: same message, different form. 26.0.0: ERROR [org.keycloak.quarkus.runtime.configuration.mappers.PropertyMappers] (main) Hostname v1 options [hostname-strict-https] are still in use. 26.7.1: WARNING: Hostname v1 options [hostname-strict-https] are still in use — no timestamp, no logger name, i.e. emitted by the CLI layer rather than the logging subsystem.
• Evidence: logs from both runs, quoted above.
• Cause: suspected — the message moved from the logger to CLI-level output between these versions. Not confirmed against release notes.
• Would this hit a customer? Only as an alerting artifact: anyone who wrote a log-scraping rule against the 26.0.0 ERROR form will silently stop matching on 26.7.x. Minor, but it is exactly the kind of thing that erodes trust in an alerting pipeline.
• Additionally on 26.7.1: WARNING: With HTTPS not enabled, proxy-headers unset, and hostname-strict=false, the server is running in an insecure context. Expected for this lab config; would be a real finding on a customer system.

Rollback

• Exercised this run? no
• Method: snapshot baseline-26.0.0-typical-1k exists, not restored
• Verdict: not established.

Verification

Publishable extract

Withheld — the headline observation is explicitly unconfirmed.