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.9 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn |
|---|---|---|---|---|---|---|---|---|
| REFERENCE | unknown-is-a-third-result | 모르는 것은 성공도 실패도 아닌 세 번째 결과여야 한다 | commit-ambiguity-as-a-result | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:unknown-is-a-third-result |
모르는 것은 성공도 실패도 아닌 세 번째 결과여야 한다
목적
완료 여부를 알 수 없는 상태를 성공이나 실패로 접어서 그 정보가 영원히 사라지는 것을 막는다.
규칙
-
결과 타입에 세 번째 변형이 있는가를 묻는다 호출자가 재시도와 조정을 구별하려면 그 구별을 담을 값이 필요하다. boolean 이나 예외 하나로는 표현되지 않는다.
-
접으면 정보가 복구되지 않는다 모르는 것을 실패로 접으면 재시도가 일어나고 커밋됐을 수도 있는 쓰기가 중복된다. 성공으로 접으면 확인되지 않은 작업이 확인된 것으로 하류에 흘러간다. 어느 쪽도 나중에 되돌릴 수 없다.
-
세 번째 변형은 조정 정보를 함께 들고 다닌다 상태 이름만으로는 부족하다. 마지막으로 관측된 단계와 조정에 쓸 안정적인 식별자가 그 값 안에 있어야 조정이 대상을 지목할 수 있다.
-
남발하지 않는다 조정 큐가 커지면 운영자가 읽지 않고 비우는 습관을 배우고, 정작 중요한 항목이 나머지와 함께 지워진다.
적용 조건
커밋과 발행과 전달처럼 관측이 결과를 확정하지 못할 수 있는 모든 경계
이 저장소의 구현 예 : RetryDisposition.RECONCILE, TransactionResult.Indeterminate, WriteDisposition.UNDETERMINED, PublishCompletion.AMBIGUOUS, GrpcBusinessEvidence.COMMIT_UNKNOWN, ReplicaLagMonitor.replayedThrough 의 Optional 반환
예외
아무것도 프로세스를 떠나지 않은 실패는 확정적이다. 세 번째 변형이 아니라 확정 실패다.
예시
change stream 파이프라인에는 본 적 있지만 완료되지 않은 위치라는 상태가 없었다. 그래서 재전달된 이벤트가 이미 처리된 것과 같은 값으로 다뤄져 영구히 사라졌다.
커밋 증거 열거형은 UNKNOWN 을 실제 상태로 두고, 드라이버가 커밋도 롤백도 확인해 주지 못한 경우를 어느 쪽으로도 접지 않는다.
관계
- pg_terminate_backend가 57P01로 도착하고 커밋 레코드는 이미 WAL에 있었다 세 번째 결과가 필요한 대표 사례다.
- high-water mark가 본 위치를 뜻해서 재전달된 변경이 영구히 사라졌다 세 번째 결과가 없어서 손실이 난 사례다.
- completion-unknown은 자동으로도 수동으로도 재시도하지 않는다 이 규칙을 정책으로 옮긴 결정이다.