여기서 일어나고 있는 일은 다음과 같습니다.
-
일부 사용자의
app.yml파일에 저장소 URL로 제 개인 GitHub 사용자명이 포함된 매우 오래된 버전의 질문 답변(Question Answer) 플러그인이 설치되어 있습니다. -
저는 몇 년 전 QnA 플러그인을
paviliondev로 이전했습니다. GitHub는 저장소가 이전되면 URL을 리다이렉트하므로, 제 개인 사용자명이 포함된 기존 URL도 계속 작동했습니다. -
그 후 몇 년이 지나 Pavilion이 질문 답변 플러그인을 Discourse로 이전했습니다. Discourse는 처음에
discourse-question-answer라는 이름을 유지했습니다. -
몇 달 전, 해당 플러그인이 여전히
discourse-question-answer로 불리던 시절에discourse조직 내의 플러그인 자체 포크를 생성했습니다. -
제 개인 GitHub 계정으로 연결된 매우 오래된 QnA 플러그인 링크를 가진 사용자들은 이제
discourse에 호스팅된, 상당 부분 업데이트된discourse-question-answer의 제 새 포크를 클론하게 되었습니다. 다시 말해, 매우 오래된 링크가 이제 새 플러그인의 포크를 가리키고 있었던 것입니다. 그 사이에 수년의 시간이 흘렀음에도 불구하고 이런 상황을 예상하지 못한 점에 대해 사과드립니다. 해당 포크는 삭제했습니다. -
Discourse는
discourse-question-answer의 이름을discourse-upvotes로 변경했습니다. 이 이름 변경은 @Jaap-Jan_Swijnenburg 님의 사례에 실질적인 영향을 미치지 않았지만, 이것이 바로 (예상치 못하게) 해당 저장소의 포크를 클론하게 된 이유입니다. -
discourse/discourse-upvotes(구discourse-question-answer)의 마이그레이션은post_custom_fields의value컬럼이 JSON으로 타입 안전하다고 가정합니다. -
플러그인이
angusmcleod/discourse-question-answer이던 시절(몇 년 전)에 생성된 오래된 데이터는discourse/discourse의HasCustomFieldsconcern에 의해 유효한 JSON으로 저장되지 않았습니다. 추측컨대, 이 데이터는 아마도 JSON 타입 확인이 추가되기 4년 전에 추가되었을 것입니다(JSON으로 등록된 커스텀 필드에서도 엣지 케이스로 인해 유효하지 않은 JSON이 생성될 수 있습니다).
따라서
app.yml에 (수년 전의)angusmcleod/discourse-question-answerURL을 가진 사용자가 Discourse를 업데이트할 때, 새 버전의 플러그인에서 마이그레이션이 클론되고 실행되며, 이로 인해 잠재적으로 이 오류가 발생할 수 있습니다.
이 문제를 해결하는 몇 가지 방법이 있습니다.
-
@Jaap-Jan_Swijnenburg 님의 경우, 제 오래된 QnA 플러그인에 대한 참조를 제거하면 사이트를 다시 빌드할 수 있습니다. 그것뿐입니다; 그 이상은 없습니다. 이미 그렇게 하신 것으로 보입니다
-
discourse/discourse-upvotes플러그인의 마이그레이션을 업데이트하여post_custom_fields의value컬럼에 있는 비-JSON 값을 처리하도록 할 수 있습니다.
2번 방안은 실제로 오래된 버전의 QnA 플러그인에서 discourse-upvotes로 전환하려는 사용자들의 추가적인 경우를 처리할 수도 있음을 언급하고 싶습니다. 그 경우 마이그레이션이 실행되며, post_custom_fields의 value 컬럼에 유효하지 않은 JSON 항목이 하나라도 있으면 실패하게 됩니다.