---
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은 자동으로도 수동으로도 재시도하지 않는다**
  이 규칙을 정책으로 옮긴 결정이다.