DongHyeonkaandClaude Opus 5
b9f4ef7bc2
A-7 left the cause as a hypothesis and said to confirm it with the statement logging A-3 used. Doing that shows the hypothesis was wrong. Login issues no SQL at all in volatile mode. Refresh issues exactly one statement, and it is not the one A-7 guessed: select cscme1_0.SCOPE_ID from CLIENT_SCOPE_CLIENT cscme1_0 where cscme1_0.CLIENT_ID=$1 and cscme1_0.DEFAULT_SCOPE=$2 parameters: $1 = '131a9912-...', $2 = 'f' REVOKED_TOKEN never appears. DEFAULT_SCOPE='f' means this is the optional client scope list, which refresh needs because it recomputes which scopes go into the new access token. The larger finding is that A-7's table was conditional and did not say so. The single statement is issued once and then cached, so the same configuration produces three different outcomes depending only on cache warmth — all three reproduced: fully cold login 400 (select ce1_0.ID from CLIENT ...) CLIENT warm login 200, refresh 500 <- what A-7 measured fully warm login 200, refresh 200 So "volatile means you can log in without a database" is also conditional: on a cold start the client lookup itself fails. In each case the Keycloak log names the failing SQL directly, so this is determined rather than inferred. A-7 keeps its original wording with a correction banner above it, so what was mis-guessed and why stays visible. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A-7a — volatile refresh 500 의 원인 확정 증거
2026-09-04 11:18 – 11:24 UTC
해설: docs/experiment-a7a-volatile-cause.md
| 파일 | 무엇을 보여주는가 |
|---|---|
01-cause-determined.txt |
가설이 틀렸다. REVOKED_TOKEN 이 아니라 CLIENT_SCOPE_CLIENT 조회다. 문장 로깅으로 잡고, 실패 로그가 그 SQL 을 직접 지목한다. 그리고 같은 설정에서 캐시 온도만으로 400/500/200 셋이 나온다 |
핵심 네 줄
- 원인은 선택적 클라이언트 스코프 조회다.
select cscme1_0.SCOPE_ID from CLIENT_SCOPE_CLIENT where CLIENT_ID=? and DEFAULT_SCOPE=?— A-7 이 지목한REVOKED_TOKEN은 로그에 한 번도 안 나온다. - 로그인은 SQL 을 0개 쏜다. refresh 만 이 한 문장을 쏘고, 그것도 첫 번째만 쏜다. 이후로는 캐시된다.
- A-7 의 표가 조건부였다. 완전 냉시동이면 로그인부터 400, 캐시가 완전히 더우면 refresh 도 200. A-7 이 본 「로그인 200 · refresh 500」은 그 사이의 한 상태다 — 셋 다 재현했다.
- 교훈 — volatile + DB 정지의 동작은 "무엇을 하느냐"가 아니라 "그 경로가 캐시를 채웠느냐" 로 갈린다. 한 번 재보고 표로 적으면 안 되는 종류의 측정이다.