개발 작업을 시작할 때 Jira에 작업을 만들고 담당자와 스프린트를 지정했습니다. 생성할 때 필드를 한꺼번에 보내면 요청 한 번으로 끝날 거라고 생각했습니다. 당시 사용한 연결 도구에서는 스프린트 값을 포함한 생성 요청이 HTTP 400으로 거절됐습니다. 값을 빼고 작업을 만들자 요청은 성공했지만, 응답에 적힌 담당자는 요청에 넣은 사람과 달랐습니다. 요청을 받아들였는지와 기대한 값이 남았는지를 따로 확인해야 했습니다.

생성과 배정을 나눠 재조회

먼저 스프린트 값을 빼고 작업을 만들었습니다. 생성 응답에서 실제 작업을 가리키는 키를 얻은 뒤, 그 작업에 상태 전환과 스프린트 배정을 요청했습니다. 생성 응답에서 다르게 표시된 담당자도 확인해 수정했습니다. 담당자가 바뀐 이유로 프로젝트 기본값을 의심했지만, 어느 설정이 적용됐는지까지는 확인하지 못했습니다.

다시 읽을 때는 이미 생성된 작업을 대상으로 삼았습니다. 작업 키, 스프린트, 상위 이슈, 연결 이슈를 조건으로 한 조회에서 한 건이 나왔고, 그 작업의 상태도 진행 중으로 표시됐습니다. 조회가 0건이면 여러 조건 가운데 무엇이 어긋났는지 드러나지 않습니다. 그때는 작업 키로 한 건을 먼저 읽고 필요한 필드를 각각 확인하는 편이 원인을 찾기 쉽습니다.

7초 차이로 생성된 중복 작업

별도의 병렬 작업에서는 같은 엔드포인트를 맡은 Jira 항목이 7초 차이로 두 개 만들어졌습니다. 두 항목의 본문, 담당자, 생성 시각을 함께 읽어 같은 작업이라는 것을 알아냈습니다. 먼저 생긴 항목에서 원래 작업을 이어 갔고, 다른 항목은 확인을 거쳐 실행 이미지 작업으로 범위를 좁혔습니다. 검색 결과에 왜 다른 항목이 나오지 않았는지까지는 기록으로 확정할 수 없었습니다.

생성 요청 뒤 응답이 끊겨 결과를 모른다면 같은 요청을 바로 반복하기보다, 대상과 범위가 같은 항목이 이미 있는지 먼저 조회할 수 있습니다. 여러 세션이 같은 범위의 작업을 여는 환경이라면 생성 담당을 먼저 정하는 방법도 있습니다. 이번에 확인한 결과는 두 항목을 조회해 중복을 찾아냈다는 데까지입니다. 사전에 담당을 정하는 방식이 중복을 막는지는 검증하지 않았습니다.