DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.7 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source, module
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | module | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CONCEPT | adapter-outbound-fileserver-c07 | 인식하지 못한 실패는 변경 연산이면 ambiguous로 떨어진다 | delivery-and-settlement-models | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | concept:adapter-outbound-fileserver-c07 | 2026-09-01 |
|
|
|
adapter-outbound-fileserver |
인식하지 못한 실패는 변경 연산이면 ambiguous로 떨어진다
AmbiguousFilesystemOperationDetector의 기본값이 보수적이라, 메시지 텍스트 매칭이 빗나가도 안전한 방향으로 떨어진다.
본문
AmbiguousFilesystemOperationDetector는 IOException을 네 결과로 나눈다(NOT_SENT / DEFINITELY_REJECTED / AMBIGUOUS_COMPLETION / RECONCILIATION_REQUIRED). 기본값이 보수적이다 — 인식하지 못한 실패는 변경 연산이면 ambiguous다.
AmbiguousFilesystemOperationDetector 참조 위치
:::evidence key="adapter-outbound-fileserver-c07" alt="코드베이스에서 AmbiguousFilesystemOperationDetector 를 검색한 출력 7줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="AmbiguousFilesystemOperationDetector 코드베이스 검색 — 7줄 · exit 0" zoom="true" :::
두 오분류의 값이 다르다
javadoc이 비대칭을 적는다: "the cost of a wrong 'safe to retry' is a corrupted object, while the cost of a wrong 'ambiguous' is one reconciliation entry." mutating 인자로 순수 읽기는 결코 ambiguous가 되지 않게 하고, stale handle은 변경 연산일 때 RECONCILIATION_REQUIRED로 격상한다 — 에러만으로는 결과를 알 수 없으므로 물리 증거를 다시 읽어야 한다.
분류가 메시지 문구에 걸려 있다
isStaleHandle·isLostResponse와 FilesystemFailureClassifier.isOutOfSpace가 메시지 텍스트 매칭에 의존한다("stale file handle", "estale", "timed out", "No space left on device", "Disk quota exceeded"). 후자에는 주석이 붙어 있다 — "The JDK has no dedicated exception for this, so the reason text is the only available signal." 로케일이나 JDK 판본에 따라 문구가 달라지면 분류가 기본값으로 떨어지는데, 기본값이 보수적(변경 연산 → ambiguous)이므로 안전한 방향이다. 기록만 한다.