완료한 task를 id로 다시 조회하니 TASK_NOT_FOUND가 돌아왔습니다

이 글은 커밋 81eb16c92ad2 하나를 근거로 씁니다. 커밋에 적힌 것 밖의 이야기는 넣지 않았습니다.

무엇을 하던 코드인가

교정 회수는 제안한 원안과 SP의 현재 상태를 대조해서 이뤄집니다. 사용자가 subtask를 고쳐 놓으면, 원안과 지금 상태를 맞대 보는 구조입니다.

알려진 것: 당시 기대는 기록에 없습니다

이 코드를 처음 짤 때 완료된 task도 id로 계속 조회될 거라고 기대했는지는 커밋에 적혀 있지 않습니다. 확인할 수 없는 부분이라 미확인으로 둡니다. 다만 커밋이 이 상황을 “구멍"이라고 부른 것으로 보아, 수정 전 해당 대조 경로는 아카이브로 옮겨진 task를 찾지 못했습니다.

실제로 확인한 것

사용자가 task를 완료하면 SP가 그 task를 아카이브로 옮기고, GET /tasks/:id는 TASK_NOT_FOUND를 냅니다. 커밋은 ?source=all이 목록 라우트에는 있고 id 라우트에는 없다고 적고, 이것을 실측으로 표시해 두었습니다.

그래서 사용자가 subtask를 고쳐 놓고 그 일을 끝내면, 원안과 현재 상태를 대조하는 경로가 그 task를 찾지 못하고 실패합니다. 커밋은 이것을 학습 기회가 사라지는 구멍이라고 불렀습니다.

차이: 찾는 길도, 읽는 길도 달랐습니다

고친 방법은 이렇습니다. 활성에서 못 찾으면 아카이브 목록을 받아 id로 거릅니다.

여기서 하나가 더 나왔습니다. 아카이브 항목은 자식을 subTaskIds가 아니라 비정규화된 subTasks 필드에 들고 있었습니다. task를 찾는 경로가 갈린 것에 그치지 않고, 자식을 읽는 경로도 따로 두어야 했다는 뜻입니다.

반환에는 archived 플래그를 넣어 어느 경로로 읽혔는지 드러냈습니다. 대조할 때는 자식의 isDone도 함께 봅니다. 커밋은 이것으로 어느 단계까지 진행되고 어디서 멈췄는지가 보인다고 적었습니다.

확인한 범위

커밋 기록에 따르면 활성·아카이브·없는 id의 세 경로를 실제로 호출해 확인했습니다. 제공된 기록에는 세 경로 각각의 상세 응답이 제시돼 있지 않아 이 글에서도 옮기지 않습니다.

그래서 무엇이 달라지는가

이 사례에서 드러난 것은 두 가지입니다. 첫째, 목록 라우트에 있는 ?source=all이 id 라우트에는 없어서 완료 task를 id로 다시 찾으려면 아카이브 경로를 따로 가져야 했습니다. 둘째, 아카이브에서 꺼낸 항목은 자식 필드의 형태가 달라서 찾는 코드와 읽는 코드가 둘 다 갈렸습니다.

이 사례 하나로 다른 API도 그렇다고 말할 수는 없습니다. 제가 이 커밋에서 가져가는 것은 질문 하나입니다. 내가 쓰는 API에서 완료되거나 보관된 항목이 id 조회에 남는가. 이 사례에서는 남지 않았습니다.