DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
5.9 KiB
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-a19-f004 | 스키마 호환성 검증기는 출하 leaf에 있고, main 코드에서 호출되지 않는다 | messaging-and-outbox | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a19-f004 | 2026-09-01 | case-analysis-finding-a19-f004.body.md |
|
|
|
스키마 호환성 검증기는 출하 leaf에 있고, main 코드에서 호출되지 않는다
검증기의 주 참조가 0 건이다. 그것이 거부하도록 만들어진 검사 없음 모드는 설정으로 켤 수 있고, 그 설정을 막는 다른 규칙도 없다. 게다가 검증기가 읽어야 할 이력의 출처 자체가 프로덕션에 없다.
관계
- 호환성 게이트를 가진 두 포맷은 build-only이고 출하되는 유일한 코덱에는 게이트가 없다 같은 공백의 다른 면이다.
- 8개 profile validator 중 조립에서 실행되는 것은 3개다 같은 가족의 같은 형태다.
- 검사하지 않는 모드는 설계 중에는 유용하고 보존 로그가 생긴 뒤에는 위험하다 자바독이 적은 근거다.
문제
스키마 호환성 검증기가 출하 리프에 있다.
주 참조를 셌다.
결론
0 건이다. 테스트 하나뿐이다.
이 클래스가 하는 일은 둘이다.
하나는 호환성 모드에 따라 비교해야 할 후보 판본 목록을 돌려주는 것이다. 이행 모드면 전체 이력이고 짝 모드면 직전 하나다.
다른 하나는 검사 없음 실험 모드를 운영 목적지에서 거부하는 것이다.
두 번째의 근거가 클래스 자바독에 있다.
아무것도 검사하지 않는 모드는 메시지 타입을 설계하는 동안에는 유용하고 보존 로그가 생기면 능동적으로 위험하다는 것이다. 로그가 그것을 아직 읽을 수 있는 모든 소비자보다 오래 살기 때문이라는 것이다.
그리고 그 모드는 설정으로 켤 수 있다.
목적지 설정의 기본값이 안전한 값이지만, 설정으로 검사 없음 실험 모드를 쓰면 그대로 통과한다.
목적지 프로파일 검증기의 열여섯 규칙에 스키마 항목이 없고, 거부 메서드는 호출되지 않는다.
부수적으로 스키마 저장소에는 주 구현이 하나도 없다.
유일한 구현은 검증기 테스트 안의 고정 저장소다.
즉 검증기가 읽어야 할 스키마 이력의 출처 자체가 프로덕션에 존재하지 않는다. 호출하려 해도 넘길 저장소가 없다.
같은 가족에서 코덱 저장소가 겪었고 등록 목록 타입으로 해결된 것과 같은 모양이고, 이쪽은 아직 해결되지 않았다.
실패 시나리오는 이렇다.
운영자가 한 목적지에 검사 없음 모드를 설정한다. 설계 중이라는 정당한 이유다.
그 설정이 그대로 프로덕션으로 나간다.
보존 로그에 이전 판본으로 쓴 메시지가 남고, 이후 판본이 필드를 삭제하면 그 로그를 읽는 소비자가 깨진다.
판정은 P2 다.
검증 환경
확인 방식 : 참조 계수와 설정 경로 확인, 저장소 구현 검색 소스 수정 : x
재현 조건
원문은 final/evidence/raw/252 계열에 있다.
- 검증기의 주 참조를 센다.
- 두 메서드가 무엇을 하는지 읽는다.
- 클래스 자바독의 거부 근거를 읽는다.
- 목적지 설정에서 호환성 모드의 기본값과 설정 가능성을 확인한다.
- 목적지 프로파일 검증기의 규칙에 스키마 항목이 있는지 확인한다.
- 스키마 저장소의 주 구현을 검색한다.
본문
SchemaCompatibilityValidator(messaging-schema-api, 출하)의 main 참조는 0건이다. 테스트 1개뿐.
SchemaCompatibilityValidator 참조 위치
:::evidence key="analysis-finding-a19-f004" alt="코드베이스에서 SchemaCompatibilityValidator 를 검색한 출력 2줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="SchemaCompatibilityValidator 코드베이스 검색 — 2줄 · exit 0" zoom="true" :::
이 클래스가 하는 일 둘
versionsToCheck(subject)— 호환성 모드에 따라 후보 스키마를 비교해야 할 버전 목록(transitive면 전체 이력, pairwise면 직전 하나)을 돌려준다.requireProductionMode(subject, destination)—NONE_EXPERIMENTAL을 production destination에서 거부한다.
두 번째의 근거가 클래스 javadoc에 있다 — "NONE_EXPERIMENTAL is refused for production destinations. A mode that checks nothing is useful while a message type is being designed and actively dangerous once a retained log exists, because the log outlives every consumer that could still read it."
그리고 그 모드는 설정으로 켤 수 있다
DestinationSettings.Schema의 @DefaultValue("BACKWARD_TRANSITIVE")가 안전한 값이지만, app.messaging.destinations.<name>.schema.compatibility=NONE_EXPERIMENTAL을 쓰면 그대로 통과한다 — DestinationProfileValidator의 16개 규칙에 스키마 항목이 없고(§3.5), requireProductionMode는 호출되지 않는다.
넘길 registry 자체가 없다
SchemaRegistry에는 main 구현이 하나도 없다. 유일한 구현은 SchemaCompatibilityValidatorTest의 FixedRegistry다. §3.5의 MessageCodecRegistry가 겪었고 RegisteredMessageCodecs로 해결된 것과 같은 모양이며, 이쪽은 아직 해결되지 않았다. P2.
확인하지 못한 것
검사 없음 모드를 설정하고 판본을 진화시켜 소비자가 깨지는 것을 재현하지 않았다. 호출 부재상 그 결과가 나온다.