Skip to content

링크 등록 재시도가 한도를 깎고 409 로 실패하는 문제 해소 #973

Description

@m-a-king

응답이 유실된 뒤 클라가 같은 URL 로 재시도하면 두 가지가 어긋난다.

  1. 이미 담긴 상품이라 409 가 나가고 클라는 이를 "담기 실패"로 표시한다. 실제로는 담겨 있어 서버와 클라의 상태가 어긋난다.
  2. 한도 차감이 중복 판정보다 앞에 있어, 409 로 끝나는 재시도도 몫을 깎는다. 사용자는 담지도 못한 채 한도만 잃고, 그 몫은 돌아오지 않는다.

같은 구조가 토너먼트 링크 담기에도 있다. 409 와 오너 몫 차감이 같은 순서다.

서버 입장에서는 재시도와 "사용자가 진짜 두 번 담으려는 시도"를 구분할 수 없다. 링크라는 자연 키가 이미 있는데도 그 판정 결과를 실패로 표현하고 있는 것이 원인이다.

무엇을

  1. 한도 차감을 중복 판정 뒤로 옮긴다. 거부되는 요청이 몫을 깎지 않는다.
  2. 중복 등록 409 를 200 get-or-create 로 바꾼다. 재시도가 기존 위시를 성공으로 받는다. refactor: from-play-link 재호출 시 409 대신 기존 CLONE id 반환 (idempotent) #470 이 from-play-link 에서 같은 전환을 이미 했다.

대상은 POST /wishlists(URL 등록)와 POST /tournaments/{tournamentId}/items/link 다.

클라 합의 필요

응답 계약이 바뀐다. 409 를 받아 "이미 담긴 상품입니다"를 띄우던 화면이 있으면 200 + 기존 항목으로 바뀐다. 중복임을 UX 로 알려야 한다면 응답에 그 사실을 표시할 필드가 필요할 수 있다(등록 응답에 이미 reused·refreshNeeded 메타가 있다).

범위 밖

  • presign 발급 재시도의 한도 누수: 요청 본문이 contentTypes 뿐이라 자연 키가 약하다. 클라가 이미지 해시를 실어 보내는 content-addressed key 설계가 선행돼야 한다.
  • 스케줄러 중복 실행(WeeklyReport), extractor 재시도 비용도 별건이다.

연관: #910(차감의 양을 정밀화, 축이 다름), #470(같은 전환의 선례)

Metadata

Metadata

Assignees

Labels

fix외부 가시적 결함 수정

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions