device turn ID

"dedupe 키는 첫 전송 전에 존재해야 해 — 그 말은 서버가 아니라 클라이언트가 발급해야 한다는 뜻이야."

왜 ID 가 폰에서 태어나나

재시도를 dedupe 하려면, 같은 의도의 모든 시도가 같은 키를 지녀야 해. 이제 물어: 그 키가 처음 존재해야 하는 게 언제야? 캡처 때 — 바로 첫 전송 전에 — 야. 첫 전송이 바로 그 확인이 잃어져서, 맞는 키가 필요한 재시도를 강제하는 그거일 수 있으니까. 서버가 ID 를 발급하면, 폰은 응답이 돌아올 때까지 그걸 못 가지고, 잃은 응답은 재시도를 맞출 키 없이 남겨. 그래서 device turn ID 는 폰에서, 캡처 시점에 발급되고, 첫 시도부터 모든 시도랑 함께 다녀.

키 하나, canonical 로그에 쓰임

device turn ID 는 폰 쪽 디테일만이 아냐. 그게 식별하는 턴이랑 나란히 canonical 로그에 기록돼. 그게 로컬 추측이 아니라 진짜 dedupe 키로 만드는 거야: 백엔드가 그걸 영속하니까, 이미 완료된 걸로 본 ID 를 지닌 두 번째 요청이 도착하면, 반복을 알아보고 작업을 다시 하는 대신 기존 결과를 돌려줄 수 있어. 키는 폰이랑 백엔드가 불안한 링크 너머로 '이건 같은 턴이야'에 합의하게 해주는 공유 어휘야.

발급: 기기에서, 캡처 때, UUID 로 — 조율 없이 전역 유일.
영속: 로컬 outbox 랑 턴이 도착하면 canonical 로그에.
운반: 그 의도의 모든 배달 시도랑 모든 재시도에, 안 바뀐 채.

안정된 정체성이 트릭 전부

힘은 전부 ID 가 시도들에 걸쳐 안정된 데서 와. 재시도마다 새 ID 를 만들면 목적을 깨버려 — 백엔드가 한 턴의 세 시도가 아니라 세 개의 다른 턴을 봐. 규율은 엄격해: 의도 하나, ID 하나, 그 턴의 수명 동안. 캡처 때 한 번 발급하고, 즉시 영속하고, 몇 번을 다시 보내든 절대 재생성 안 해. 다음 레슨들이 하는 모든 것 — 부르기 전 확인, 더블 전송 피하기 — 이 이 식별자 하나가 상수로 남는 데 기대.

Code

캡처 때 한 번 발급; 모든 시도에 안 바뀐 채 운반·typescript

// 캡처 때 — 어떤 네트워크 시도 전에도 — 안정된 키를 발급.
function createTurn(question: string, attachmentIds: string[]): PippaGoTurn {
  return {
    deviceTurnId: crypto.randomUUID(), // 기기에서, 한 번, 캡처 때
    question,
    attachmentIds,
    syncStatus: "pending",
  };
}

// 모든 배달 시도가 같은 id 를 보냄. 재시도는 재사용하지 새로 발급 안 함.
async function deliver(turn: PippaGoTurn) {
  return callCanonical({ ...turn, idempotencyKey: turn.deviceTurnId });
}

// 틀림: deliver() 안에서 `idempotencyKey: crypto.randomUUID()` —
// 시도마다 새 키는 세 재시도를 세 턴처럼 보이게 만들어.

Exercise

턴 하나의 device turn ID 를 추적해: 캡처, 첫 전송(ack 잃음), 재시도, 백엔드 인식. 각 단계에서 ID 값을 적고 절대 안 바뀌는 걸 확인해. 그다음 일부러 깨봐 — 재시도에 ID 재생성 — 그리고 백엔드가 이제 뭘 보고 왜 사용자가 두 번 청구되거나 답받을 수 있는지 정확히 묘사해.

Hint

안정된 ID 면 백엔드의 두 번째 시야는 '아, turn X 또 왔네 — 이미 했어, 여기 답' 이야. 재생성된 ID 면 두 번째 시야는 '완전 새 turn Y' 라서 작업을 다시 해. 같은 코드 경로, 반대 결과, 전적으로 키가 상수로 남았냐로 갈려.