일정 기간 동안 여러 Discourse 사이트를 운영해 왔고, Discourse의 API와 직접 상호작용하는 여러 스크립트를 보유하고 있습니다. 업그레이드 이후 주기적으로 기능이 갑자기 작동하지 않는 경우가 발생하며, 즉시 감지할 수 있는 문제라면 괜찮지만, 시간이 좀 지나서야 문제가 드러나면 원인을 파악하기가 어려워지고, 개발 인스턴스 대신 프로덕션 환경에서 문제가 발생하는 경우가 많습니다.
최근에 include_expired 옵션이 제거되었는데, 불행히도 캘린더 API에서 만료되지 않은 이벤트만 반환되도록 하는 동작은 제가 의존하고 있던 것이었습니다. 이로 인해 업그레이드 후 상당한 시간이 지난 후에 여러 프로세스가 오류를 일으켰습니다. 이 특정 사례의 경우, 이제 제거된 매개변수를 지정하는 호출자가 있었다면 적어도 제 스크립트에서는 문제가 즉시 중단되었을 것입니다.
따라서 제가 궁금한 것은 Discourse의 다운스트림 사용자로서, 이러한 API 변경 사항이 제 인스턴스에 영향을 주기 전에 어떻게 식별할 수 있는지에 대한 것입니다. 이전에는 이러한 문제를 피하기 위해 discourse-calendar 저장소를 미러링하고 제 시간대로 덜 자주 업그레이드하는 방법을 사용했습니다. 하지만 이제 통합이 이루어졌기 때문에 그 접근 방식을 중단했는데, 다시 같은 문제에 부딪히고 있습니다.
Discourse가 지속적으로 겪고 있는 노력과 개선 사항에 감사드립니다. 답변이 "엔터프라이즈에 가입하면 이런 일이 덜 발생합니다"이거나 "귀사 측에서 더 많은 테스트를 추가하십시오
저도 비슷한 종류의 오류를 겪었지만, 다른 접근 방식을 선택했습니다. 캘린더 API 엔드포인트를 직접 호출하는 대신, 내 가져오기(importer) 도구가 [event] BBCode를 생성하여 Discourse에 게시합니다. 그러면 플러그인이 스태프 사용자가 수동으로 이벤트를 생성한 것처럼 이를 파싱합니다. 이렇게 하면 include_expired와 같은 일시적인 쿼리 파라미터에 의존하는 문제를 피할 수 있고, 더 안정적인 계약(plain posts and BBCode)을 얻을 수 있습니다. 이러한 형식이 사전 통보 없이 변경될 가능성은 낮기 때문입니다.
[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Meet to discuss Discourse RESTful API
[/event]
이 방식의 트레이드오프는 제 쪽에서 더 많은 노력이 필요하다는 점입니다. ICS 데이터를 올바르게 이스케이프된 [event] 태그로 변환하는 포맷터를 작성해야 했으며, 종일 이벤트와 시간 지정 이벤트를 처리하는 등 다양한 사항을 다뤄야 했습니다. 하지만 실제 운영에서는 이 방식이 업그레이드 과정에서 훨씬 더 견고했습니다. 이는 업스트림의 비추천(deprecation) 공지 필요성을 완전히 제거하지는 못합니다(옵션이 제거될 때 API가 빠르게 실패하거나(fail fast) 최소한 경고하기를 여전히 원합니다). 그러나 스크립트가 조용히 깨지는 위험성은 크게 줄였습니다.
