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>
58 lines
2.9 KiB
Markdown
58 lines
2.9 KiB
Markdown
---
|
|
kind: REFERENCE
|
|
slug: unknown-is-a-third-result
|
|
title: 모르는 것은 성공도 실패도 아닌 세 번째 결과여야 한다
|
|
topic: commit-ambiguity-as-a-result
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: reference:unknown-is-a-third-result
|
|
verifiedOn: # 이 기록은 이번 회차에 실행 확인을 하지 않았다
|
|
---
|
|
|
|
# 모르는 것은 성공도 실패도 아닌 세 번째 결과여야 한다
|
|
|
|
## 목적
|
|
|
|
완료 여부를 알 수 없는 상태를 성공이나 실패로 접어서 그 정보가 영원히 사라지는 것을 막는다.
|
|
|
|
## 규칙
|
|
|
|
1. 결과 타입에 세 번째 변형이 있는가를 묻는다
|
|
호출자가 재시도와 조정을 구별하려면 그 구별을 담을 값이 필요하다. boolean 이나 예외 하나로는 표현되지 않는다.
|
|
|
|
2. 접으면 정보가 복구되지 않는다
|
|
모르는 것을 실패로 접으면 재시도가 일어나고 커밋됐을 수도 있는 쓰기가 중복된다. 성공으로 접으면 확인되지 않은 작업이 확인된 것으로 하류에 흘러간다. 어느 쪽도 나중에 되돌릴 수 없다.
|
|
|
|
3. 세 번째 변형은 조정 정보를 함께 들고 다닌다
|
|
상태 이름만으로는 부족하다. 마지막으로 관측된 단계와 조정에 쓸 안정적인 식별자가 그 값 안에 있어야 조정이 대상을 지목할 수 있다.
|
|
|
|
4. 남발하지 않는다
|
|
조정 큐가 커지면 운영자가 읽지 않고 비우는 습관을 배우고, 정작 중요한 항목이 나머지와 함께 지워진다.
|
|
|
|
## 적용 조건
|
|
|
|
커밋과 발행과 전달처럼 관측이 결과를 확정하지 못할 수 있는 모든 경계
|
|
|
|
이 저장소의 구현 예 : 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은 자동으로도 수동으로도 재시도하지 않는다**
|
|
이 규칙을 정책으로 옮긴 결정이다.
|
|
|