All five hops reached ready; final state 26.7.3, 100,006 users intact
Index audits pass end-to-end after the two findings below are handled
Breakage observed
1. idx_client_att_by_name_value genuinely missing (pre-existing in the 21.1.2 baseline)
Symptom: audit at 22.0.5: MISSING idx_client_att_by_name_value on client_attributes.
Evidence: index absent from pg_indexes; client_attributes has 30 rows, so
the ~300k-row skip heuristic does not explain it. Changeset
14.0.0-KEYCLOAK-18286-supported-dbs is marked EXECUTED.
Cause: pre-existing in the 21.1.2 baseline (a 14.0.0 changeset predates the
hop; the 22.0.5 migration does not touch it). Not introduced by the ladder.
Fix:CREATE INDEX CONCURRENTLY idx_client_att_by_name_value ON client_attributes (name, (value::varchar(250)));
Would this hit a customer? Yes — a 21.1.2 install that skipped this index
looks migrated (schema stamp advances) while missing an index. This is exactly
the class the index-audit exists to catch, and it validates shipping the audit
as part of the runbook rather than trusting the schema version.
2. index-audit.py false positive: varchar vs character varying
Symptom: audit flagged idx_group_att_by_name_value as MISMATCH —
changelog (name, (value::varchar(250))) vs DB (name, ((value)::character varying(250))).
Cause:norm() only stripped a cast at end-of-token and did not fold the
varchar/character varying alias or collapse redundant parens. Same type,
different spelling.
Fix:bin/index-audit.pynorm() now folds charactervarying→varchar,
strips ::type[(n)] casts anywhere, and collapses redundant parens.
Would this hit a customer? No — tool-only. Re-audit passes 84/84.
Rollback
Not exercised on this path this run (exercised on the patch-hop path in run 3).