The check is structural and conservative: records, enums, strings, boxed primitives and * immutable collection views replay; anything else is treated as one-shot, so the retry engine * refuses rather than gambling. A caller who knows better can freeze the value itself — serialize * it to a {@code byte[]} body — which states the guarantee instead of asserting it. ``` 확실한 호출자에게는 값을 바이트 배열 본문으로 굳히라고 적어 뒀다. 아래는 그 권고를 따르지 않은 값에 대한 이야기다. 판정의 첫 분기는 이렇다. ```java if (candidate instanceof String || candidate instanceof Number || candidate instanceof Boolean || candidate instanceof Character || candidate instanceof Enum || candidate instanceof java.util.UUID || candidate instanceof java.time.temporal.Temporal) { return true; } ``` 선언에 없는 분기가 셋이다. `Number` 와 `UUID` 와 `Temporal`. `UUID` 는 불변이고 `Temporal` 은 표준 구현체가 전부 불변이라, 남는 것은 `Number` 한 줄이다. 상자 원시형만이 아니라 `Number` 를 상속하는 모든 타입이 들어온다. ## 넣어 보면 :::evidence key="a11-f004-number-bytes" alt="기본 설정의 REST 클라이언트가 JSON 본문을 쓸 때 고르는 변환기, 원자 계열 여섯 타입을 각각 본문 값으로 넣어 받은 판정, 큰 정수와 큰 십진수가 더하기 뒤에도 자기 값을 유지하는 것과 원자 정수가 바뀌는 것의 대조, 성분에 카운터를 둔 레코드의 판정과 그 변환기로 두 번 인코딩한 결과와 바이트 동일성 비교, 그리고 호출자가 쥔 컬렉션과 그것을 감싼 레코드의 판정을 출력한 터미널 기록." caption="요청 경로의 JSON 변환기는 Spring 의 JacksonJsonHttpMessageConverter · 원자 계열 여섯 타입이 전부 REPLAYABLE · 큰 정수와 큰 십진수는 더하기 뒤에도 자기 값 그대로 · 카운터를 둔 레코드는 판정이 그대로인 채 인코딩이 attempt 1 에서 2 로 바뀐다 — 35줄 · exit 0" zoom="true" ::: ```text [java.util.concurrent.atomic 의 Number 하위 타입] AtomicInteger Number 상속 true 판정 REPLAYABLE AtomicLong Number 상속 true 판정 REPLAYABLE LongAdder Number 상속 true 판정 REPLAYABLE DoubleAdder Number 상속 true 판정 REPLAYABLE LongAccumulator Number 상속 true 판정 REPLAYABLE DoubleAccumulator Number 상속 true 판정 REPLAYABLE ``` 여섯 다 값을 바꿀 수 있는 타입이고, 여섯 다 통과한다. `Number` 를 상속했다는 것 말고 공통점이 없다. 상자 원시형과 이 여섯 사이에 남는 표준 타입은 둘뿐이다. ```text [상자 원시형과 원자 계열 사이에 남는 둘] BigInteger add 뒤 자기 값 7 판정 REPLAYABLE BigDecimal add 뒤 자기 값 7.5 판정 REPLAYABLE AtomicInteger increment 뒤 자기 값 8 판정 REPLAYABLE ``` 둘은 더하기를 불러도 자기 값이 그대로다. 원자 정수는 7 이 8 이 된다. 같은 판정을 받는 세 타입 중 마지막 하나만 자기를 바꾼다. ## 판정은 그대로, 바이트는 다르다 요청 경로가 JSON 본문을 쓸 때 고르는 변환기부터 확인했다. ```text [요청 본문을 인코딩하는 변환기] RestClient 기본 목록 org.springframework.http.converter.json.JacksonJsonHttpMessageConverter ``` 그 변환기로 두 번 인코딩한 결과다. ```text [성분에 카운터를 둔 record] 판정 : REPLAYABLE 첫 인코딩 : {"id":"A-1","attempt":1} 다시 인코딩 : {"id":"A-1","attempt":2} 판정(그대로) : REPLAYABLE 같은 바이트인가 : false ``` 사이에 한 것은 카운터를 올린 것뿐이다. 재시도 엔진이 읽는 값은 두 번 다 재생 가능이고, 같은 값을 다시 인코딩한 결과는 다르다. ## 이 검사가 존재하는 이유 ```text *
Every {@code ObjectBody} used to report {@code REPLAYABLE}. A caller who reused a builder or * kept a reference to a list therefore got a retry that re-encoded the value as it was at retry * time — different bytes, same idempotency key, which is precisely what a replay must never * be. ``` 이 문장은 test 클래스 javadoc 에 있다. 그 test 넷은 다른 갈래를 본다. ```text 28: @DisplayName("a record of immutable components replays") 29: void anImmutableRecordReplays() { 41: @DisplayName("a value the caller can still mutate does not replay") 42: void aMutableValueIsOneShot() { 51: @DisplayName("a record wrapping a mutable component does not replay") 52: void aRecordWrappingMutableStateIsOneShot() { 66: @DisplayName("an uninspectable value is one-shot") 67: void anArbitraryBeanIsOneShot() { ``` 입력에는 컬렉션과 맵과 빈이 들어 있고, 숫자는 상자 원시형뿐이다. `Map.of("k", 1)` 의 1 과 `ImmutableOrder` 의 int 가 그것이다. `Number` 분기 자체는 밟히지만 가변 숫자 타입은 한 번도 들어가지 않는다. ## 검사가 잡는 쪽 ```text [검사가 잡는 쪽] ArrayList 자체 판정 ONE_SHOT ArrayList 를 감싼 record 판정 ONE_SHOT List.of 를 감싼 record 판정 REPLAYABLE ``` 컬렉션 쪽은 이름으로 불변 뷰인지 확인하고 감싼 레코드까지 따라간다. 원자 카운터를 요청 객체에 넣지 않는 한 이 구멍에 닿지 않는다. ## 확인하지 못한 것 재시도 엔진을 실제로 돌려 두 번째 시도가 그 바이트를 보내는지 관측하지 않았다. 확인한 것은 판정과 인코딩까지다. 사용자 정의 시간 구현으로 같은 구멍을 재현하지 않았다.