오류 발생 시 롤백과 충돌 해결

낙관적 추가를 롤백하거나(항목 제거), 삭제를 롤백하는 것(항목 복원)은 간단합니다. 수정 작업을 롤백하는 것은 더 복잡합니다. 정확히 이전 값을 복원해야 하기 때문입니다. 항목이 낙관적으로 여러 번 수정되었다면 최초의 서버 상태만 추적해서는 안 되고, 각 이전 값을 별도로 추적해야 합니다.

다음 시나리오를 생각해 보십시오. 서버의 항목 값은 Z입니다. 이를 낙관적으로 X로 수정합니다. 요청이 진행 중인 동안 다른 사용자가 서버에서 같은 항목을 Y로 수정합니다. 요청이 서버에 도착하면 서버는 충돌로 이를 거부합니다. 롤백 대상은 Z이지만 서버의 현재 상태는 Y입니다. Z를 복원하면 Y를 잘못 덮어쓰게 됩니다.

수정 작업에서 가장 안전한 롤백 전략은 로컬에 저장한 스냅샷을 복원하는 대신, 변경 작업 오류가 발생할 때마다 서버에서 항목을 다시 조회하는 것입니다. 이렇게 하면 다른 사용자가 동시에 변경한 내용이 무엇이든 권위 있는 서버 상태를 표시할 수 있습니다. 다시 조회하는 방법은 더 느리지만 항상 올바른 결과를 제공합니다.

잘 설계된 API는 동시 수정으로 인해 낙관적 수정이 실패하면 HTTP 409 충돌을 반환합니다. 응답 본문에는 일반적으로 현재 서버 상태가 포함됩니다. 오류 처리기는 409를 감지하고, 응답 본문을 사용해 서버의 현재 값으로 로컬 상태를 업데이트한 다음 변경 사항이 저장되지 않았음을 사용자에게 알려야 합니다.

멱등성 변경 작업은 여러 번 적용해도 같은 결과를 생성합니다. 변경 작업을 멱등적으로 설계하면(PUT을 POST 대신 사용하고, 전체 리소스 상태와 멱등성 키를 포함하는 방식 등) 변경 사항이 이중으로 적용될 위험 없이 실패 시 안전하게 재시도할 수 있습니다. 따라서 롤백 로직도 훨씬 단순해집니다.

제출 버튼을 빠르게 두 번 클릭하면 동일한 변경 작업이 두 번 실행될 수 있습니다. isSubmitting 플래그로 이를 방지하십시오. 변경 작업이 시작되면 true로 설정하고, 성공 또는 실패 여부와 관계없이 완료되면 초기화합니다. isSubmitting이 true일 때 실행 요소를 비활성화하십시오. 이렇게 하면 사용자 인터페이스 수준에서 중복 변경 작업을 제거할 수 있습니다.

서버 측에서 중복을 제거하려면 각 변경 작업 요청에 고유한 Idempotency-Key 헤더를 포함하십시오. 사용자가 작업을 시작할 때 crypto.randomUUID()로 키를 생성합니다. 서버는 중복 키를 감지하고 작업을 다시 적용하지 않은 채 원래 요청과 동일한 응답을 반환합니다.

변경 작업이 진행 중인 동안 낙관적 상태가 아직 확인되지 않았음을 보여 주는 은은한 표시를 추가할 수 있습니다. 작은 점을 깜박이게 하거나, "저장 중..."이라는 텍스트를 표시하거나, 항목의 불투명도를 낮추는 방법이 있습니다. 이렇게 하면 상호 작용을 차단하지 않고 불확실성을 전달할 수 있습니다. 성공하면 표시를 제거하고, 실패하면 롤백하면서 제거하십시오.

롤백 로직에서 발생한 예기치 않은 오류(예: 상태를 복원하는 중 정의되지 않은 값의 속성에 접근하는 경우)는 컴포넌트를 중단시킬 수 있습니다. 변경 작업이 많은 컴포넌트를 오류 경계로 감싸면 치명적인 롤백 실패가 빈 화면 대신 적절한 오류 사용자 인터페이스로 표시됩니다. 디버깅을 위해 이러한 오류를 기록하십시오.

신뢰할 수 있는 충돌 감지 전략은 모든 변경 작업에 버전 번호 또는 ETag를 포함하는 것입니다. 서버는 클라이언트가 보낸 버전과 현재 버전을 비교합니다. 두 버전이 다르면(다른 수정 작업이 발생했으면) 409를 반환합니다. 이것은 낙관적 동시성 제어입니다. 충돌이 없다고 가정하되 충돌이 발생하면 감지하는 방식입니다.

네트워크 오류는 시뮬레이션하기 어렵기 때문에 롤백 로직은 테스트되지 않는 경우가 많습니다. Mock Service Worker와 같은 도구를 사용해 테스트에서 오류 응답을 반환하십시오. 다음 항목에 대한 테스트를 명시적으로 작성하십시오. 409 충돌 처리, 네트워크 시간 초과 롤백, 이중 클릭 중복 제거, 실패 후 상태 일관성입니다. 버그는 이러한 예외 상황에 숨어 있는 경우가 많습니다.

다른 사용자의 동시 수정으로 인해 낙관적 수정이 실패할 때, 잘 설계된 API는 어떤 HTTP 상태 코드를 반환합니까?

수정 작업의 롤백은 추가 또는 삭제보다 복잡하므로, 오래된 스냅샷 문제를 피하려면 오류 발생 시 항상 다시 조회해야 합니다. HTTP 409 충돌은 낙관적 동시성 제어 실패를 나타냅니다. 응답 본문을 사용해 서버의 현재 상태를 복원하십시오. 안전한 재시도를 위해 변경 작업을 멱등적으로 설계하십시오. isSubmitting과 서버 측 멱등성 키를 사용해 이중 실행을 방지하십시오. MSW로 오류를 시뮬레이션하여 롤백 경로를 명시적으로 테스트하십시오.