document-haness/docs/clean-architecture-backend-template/tech-log-studio/notification-and-delivery/case/case-analysis-finding-a13-f010.md

kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, body, assets, evidence, source

kind	slug	title	topic	project	status	sourceRevision	rootTreeNode	evidenceCapturedOn	body	assets	evidence	source
CASE	analysis-finding-a13-f010	FCM만 "커밋 후 응답 손실 = ambiguous" 규칙 밖에 있고, 그 FCM이 두 계약 집합 어디에도 없다	notification-and-delivery	clean-architecture-backend-template	게시 전	21234e38cdb9a926cbc92bb97a2aee2e4a7d2916	case:analysis-finding-a13-f010	2026-09-01	case-analysis-finding-a13-f010.body.md	key file analysis-finding-a13-f010 ../../../final/evidence/rendered/analysis-finding-a13-f010.svg	../../../final/evidence/raw/analysis-finding-a13-f010.txt	원본 분석 절은 analysis/13-adapter-outbound-notification.md#L957 이다.

FCM만 "커밋 후 응답 손실 = ambiguous" 규칙 밖에 있고, 그 FCM이 두 계약 집합 어디에도 없다

공통 결과 변환기의 자바독이 모든 HTTP 제공자 어댑터가 전송 실패를 여기로 보낸다고 적는다. 한 제공자 경로는 그것을 지나지 않는다. 그리고 그 경로는 배치라 한 번의 손실이 최대 배치 크기만큼의 배달에 동시에 영향을 준다.

관계

• 재시도 안전은 증거로 결정된다 이 규칙이 존재하는 이유다.
• 상한을 두고 읽는다는 본문 handler가 전부 읽은 뒤에 자른다 같은 리프의 다른 P2 다.
• 모든 어댑터가 지난다고 적힌 통로에 예외가 있으면 규칙은 한 번 쓰인 것이 아니다 이 사례가 그 규칙의 형태다.

문제

공통 결과 변환기의 존재 이유가 클래스 자바독에 쓰여 있다.

모든 HTTP 제공자 어댑터가 전송 실패를 여기로 보내므로, 본문이 커밋된 뒤 응답이 없으면 모호하다는 규칙이 제공자마다 다시 유도되지 않고 한 번만 쓰인다는 것이다.

모든 어댑터가 실제로 지나는지 확인했다.

결론

한 경로가 지나지 않는다.

세 계층 전부에 번역도 방어도 없다.

게이트웨이 심은 실패 계약을 선언하지 않은 함수형 인터페이스다. 배치를 보내고 배치 결과를 돌려준다.

조정자의 제출 메서드에는 잡기도 없고 전송 변환 호출도 없다. 게이트웨이를 부르고 크기를 비교한 뒤 어긋나면 상태 예외를 던진다.

어댑터는 조정자 결과를 그대로 통과시킨다.

전송 예외 타입도 본문 커밋 비트도 이 경로에는 존재하지 않는다.

다른 여섯 어댑터가 모두 전송 예외를 잡아 공통 변환기로 보내고 모호 결과와 응답 손실 증거를 만드는 자리에서, 이 경로는 구현이 던지는 임의의 실행 예외를 그대로 올려보낸다.

실패 시나리오는 이렇다.

다중 수신 요청의 본문이 기록된 뒤 연결이 끊긴다.

배치가 최대 배치 크기만큼의 수신자를 담고 있으므로 한 번의 손실이 그만큼의 배달에 동시에 영향을 준다.

결과는 모호가 아니라 분류되지 않은 예외다.

일정 작업자의 포괄 잡기가 예외 타입을 사유로 로그를 남기고 임차를 만료시킨다.

임차 회수 서비스가 미완 시도를 보고, 증명 가능하게 시작되지 않았다가 거짓이므로 재대사로 넘긴다.

판정은 P2 다.

검증 환경

OpenJDK : 21.0.12 확인 방식 : 어댑터별 전송 실패 경로 전수 대조 소스 수정 : x

재현 조건

원문은 final/evidence/raw/173 계열에 있다.

1. 공통 결과 변환기의 클래스 자바독을 읽는다.
2. 어댑터 목록을 만들고 각각의 전송 실패 처리를 확인한다.
3. 예외 경로에 잡기가 있는지 본다.
4. 전송 예외 타입과 커밋 비트가 그 경로에 존재하는지 검색한다.
5. 그 경로가 배치인지 단건인지 확인한다.

본문

ProviderResults의 존재 이유가 클래스 javadoc에 쓰여 있다.

"Every HTTP provider adapter routes its transport failures through here, so the rule that 'committed body plus no response equals ambiguous' is written once rather than re-derived per provider."

ProviderResults 참조 위치

:::evidence key="analysis-finding-a13-f010" alt="코드베이스에서 ProviderResults 를 검색한 출력 10줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="ProviderResults 코드베이스 검색 — 10줄 · exit 0" zoom="true" :::

FCM 경로는 그것을 지나지 않는다

세 계층 전부에 번역도 방어도 없다.

// FcmGateway.java — 실패 계약이 선언되지 않은 심
@FunctionalInterface
public interface FcmGateway {
  FcmBatchResult sendBatch(List<Map<String, Object>> messages);
}

// FcmBatchCoordinator.submit — try/catch 없음, fromTransport 없음
FcmBatchResult batch = gateway.sendBatch(messages);
if (batch.items().size() != submissions.size()) { throw new IllegalStateException(...); }

// FcmNotificationProviderAdapter — 그대로 통과
return coordinator.submit(submissions);

그리고 그 FCM이 두 계약 집합 어디에도 없다. P2.

확인하지 못한 것

배치 전송 중 연결을 끊어 실제 흐름을 재현하지 않았다. 경로 구조상 그 결과가 나온다.