[corneliusroemer-agent]

The integration-test job flaked multiple times on a console 404 for a Keycloak theme asset (:8083/resources/<version>/login/loculus/…js) during login, causing the login form to never render. Between 09-23 and 09-27 it hit 5 job-attempts on 4 unrelated branches.

This is a race (bug) in Keycloak itself: keycloak/keycloak#53238 which I reported today.

KC_SPI_RESOURCE_ENCODING_GZIP_ENABLED=false is a narrow workaround for the bug. It only disables gzip encoding of theme files which should not have any impact on test correctness.

What changes

A new keycloakExtraEnv value: a list of Kubernetes EnvVar objects appended to the Keycloak container's env. values_e2e_and_dev.yaml uses it to set KC_SPI_RESOURCE_ENCODING_GZIP_ENABLED=false. With the default values the rendered manifests are byte-identical to main, so production keeps gzip encoding of theme resources.

https://claude.ai/code/session_01KGPjaZYeyyUnPSHeDUrvtX

🚀 Preview: Add preview label to enable

[claude]

This PR may be related to: #5426 (flaky CLI integration test due to Keycloak theme asset serving issue, opened the same day this fix landed).

[claude]

Claude finished @corneliusroemer's task in 23s —— View job

---

Review

The change is small and correct, and I have no code issues to flag inline. I read the template by eye; I couldn't run helm template here because it needs approval.

Template (keycloak-deployment.yaml:111-113)

• with plus toYaml | nindent 12 puts the entries at the right indent in env:. When the list is empty or unset, nothing renders, so default installs don't change.
• This follows the same pattern as backendExtraArgs.

Schema (values.schema.json:2206)

• Setting additionalProperties: false with required: ["name"] is a good choice. A misspelled key such as valeu will fail at install instead of being silently dropped.
• The schema also accepts an entry with both value and valueFrom, or with neither. Kubernetes rejects the first case at apply time and accepts the second, so neither needs a fix here.
• If an extra entry uses a name the chart already sets, Kubernetes keeps the last one. That makes this an override hook as well, which seems fine.

Workaround (values_e2e_and_dev.yaml:12-15)

• The fix is narrowly scoped, and the linked upstream issue is in a comment next to it, so it's easy to remove once Keycloak fixes the bug.
• One thing to consider: the race is in Keycloak itself, so production could in principle hit the same 404 on a cold theme asset. It shows up in e2e because many logins happen at once right after startup. Keeping production unchanged is a reasonable call, but it may be worth saying so explicitly.

PR description (only needs a wording fix)

• "so production keeps theme caching" is left over from the first commit. The final change disables gzip encoding, not the theme cache, so this should say something like "production keeps gzip encoding of theme resources".
• Typo: "causing the login form to never renders" should be "to never render".

Tests and docs: there's nothing to add beyond the schema description. The e2e CI run is the real test of whether the flake goes away.

LGTM.

[tombch]

Otherwise looks good to me!

[maverbiest]

This looks great! Would be nice to get merged, I ran into this failure mode couple of times today when running CI :)

[anna-parker]

@maverbiest I updated with @tombch's docs suggestion - as Cornelius is on vacay feel free to merge this if all tests pass :-)