mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5.5
30084f986c
In the async pass the role runs kcadm jobs side by side. Every kcadm call in the Keycloak container shares one config file. kcadm rewrites that file when it refreshes the access token, about every 55 seconds, takes the file lock with tryLock() and gives up at once when another kcadm process holds it. One of two overlapping declared-client jobs then failed with "Failed to get lock on /opt/keycloak/.keycloak/kcadm.config", and the deploy with it. keycloak_kcadm_update now repeats a call that lost the lock, up to ten times one second apart. The call fails while it refreshes its token, before it sends its own request, so repeating it is safe. Every other error still ends the call at once. That covers the module only, so the async jobs are reduced to the ones that go through it: - The default-scope assignment was an async shell task. It ran beside the shell tasks that follow it, and neither side repeats a lost lock. It runs in line now. - The two mail-settings jobs were async without a register, so nothing reaped them and a failure was never seen. They run in line now. The client job and the declared-client jobs stay async. A test fails when an async kcadm task does not use the module or is not registered for the reap. A config file of its own per call was the other option. It does not work by itself, because the admin session lives only in the shared file. Closes #805 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>