"원격 호출을 아예 안 짓는 오프라인 요청은 못 새. 그건 약속이 아니라 모양이야."
Rekindle 유산
Firekeeper 의 글쓰기 형제 Rekindle 은 오프라인 모드에 대해 빡빡한 규칙을 배웠고, Firekeeper 가 그걸 그대로 물려받아: 프로바이더 선택이 바이트 하나 프로세스를 떠나기 전에 일어남. 활성 연결 모드가 먼저 구체 프로바이더로 해결되고; 그다음에야 요청이 지어지고 보내져. 디테일처럼 들려. 사실은 진짜 오프라인과 오프라인 연극의 차이 전부야.
두 아키텍처, 하나의 치명적 차이
폴백을 구조화하는 두 방법을 비교해. 실패-시-폴백 설계는 원격 호출을 시도하고, 실패할 때만 로컬로 라우팅 — 즉 오프라인-의도 요청이 누가 확인하기 전에 이미 네트워크 호출을 시도(또는 준비)했어. 선택-전송-전 설계는 고른 모드에서 프로바이더를 미리 골라, 오프라인 요청이 로컬 프로바이더로 라우팅되고 원격 호출이 아예 안 지어져. 첫째는 아무것도 안 샜길 바라고; 둘째는 새는 걸 구조적으로 불가능하게 만들어.
실패-시-폴백 (연극):
원격 호출 짓기 -> 전송 시도 -> 실패? -> 이제 로컬로 # 원격이 시도됐어!
선택-전송-전 (진짜):
고른 모드 읽기 -> 오프라인? -> 로컬 호출만 짓기 # 원격이 존재 안 함
왜 '구조적' 이 '조심스러움' 을 이겨
실패-시-폴백을 조심스러운 확인으로 안전하게 만들 수도 있어 — '온라인일 때만 보내고, 나가기 전에 꼭 취소.' 근데 조심스러움은 취약해: 리팩터 하나, 레이스 하나, 잊은 분기 하나면 원격 호출이 새 나가. 선택-전송-전 은 조심스러움에 의존 안 해. 오프라인 모드에선 원격 요청을 짓는 코드 경로가 그냥 안 닿아, 그러니 샐 게 없어. 안전 속성이 위에 볼트로 붙인 가드가 아니라 제어 흐름의 결과일 때, 실수로 퇴행시킬 수 없어.