- Ya
- 11 Mei 2026, 18:23 UTC
- Mwandishi
- kamo
- Ahadi ya
- a274da5
The previous fix had /api/user-info call /api/security/session/refresh before reading Redis, but the read went through readKsemJsonFromRedisWithRetry which uses getRedisReadClient() — a read replica. The refresh write hits the Redis master, so on a freshly-replicated key there is a replication-lag window where the replica still serves the stale JSON. The shared retry reader only re-tries when the key is missing or empty, not when it's stale, so it returned old rights every time and pages like /settings/account kept redirecting child-org owners off Apps & Features. When the refresh succeeds, read straight from the write client (the same master that just received the write) so we always see our own write. Fall back to the shared retry reader only when no refresh ran — the replica path is cheaper and the existing retry behaviour handles missing-key races on brand-new sessions.