dubwoc
1
しばらくの間、いくつかのDiscourseサイトを運営しており、DiscourseのAPIに直接連携するスクリプトがいくつかありますが、アップグレード後に定期的に動作しなくなることがあります。通常、すぐに検出できるものであれば問題ありませんが、しばらくしてから現れると、原因の特定が困難になり、開発インスタンスではなく本番環境で問題が発生することがよくあります。
例：Recurring events in Upcoming Events calendar fail to handle daylight saving change
最近include_expiredオプションが削除されましたが、残念ながら、期限切れでないイベントのみがカレンダーAPIから返されるという動作は私が依存していたものであり、アップグレード後に多くのプロセスが後で失敗する原因となりました。この特定の場合、呼び出し元が削除されたパラメータを指定した場合に失敗していれば、少なくとも私の特定のスクリプトで問題が発生していたでしょう:slight_smile:
そのため、Discourseのダウンストリームユーザーとして、このようなAPI変更が私のインスタンスに影響を与える前に特定するための最善の方法は何でしょうか？以前は、discourse-calendarリポジトリをミラーリングし、自分の時間でアップグレード頻度を下げてこれらの問題を回避していましたが、それが統合された今、そのアプローチをやめることにし、再び問題に直面しています。
Discourseが絶えず受けているすべての作業と改善に感謝しており、「エンタープライズにサインアップすれば、これらの問題は発生しにくくなります」という答えでも構いませんし、こちらでより多くのテストを追加するというのでも構いませんが、他に知らないオプションやアプローチがあるかどうかを確認したかったのです。
ありがとうございます。
「いいね！」 4
Ethsim2
(Ethan )
2
同様の不具合に遭遇しましたが、私は別の方法を取りました。カレンダーAPIエンドポイントを直接利用するのではなく、私のインポーターは[event] BBCodeを構築し、それをDiscourseに投稿します。これにより、プラグインがスタッフユーザーが手動でイベントを作成したかのように解析します。その結果、include_expiredのような一時的なクエリパラメータへの依存を回避でき、より安定した契約を得られます。プレーンな投稿とBBCodeは、予告なく変更される可能性が低いです。
[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Discourse RESTful APIについて話し合う会議
[/event]
トレードオフとして、こちら側でより多くの作業が必要になります。ICSデータを適切にエスケープされた[event]タグに変換し、終日イベントと時間指定イベントを処理するフォーマッターを書く必要がありました。しかし実際には、このアプローチはアップグレードを通じてはるかに回復力があります。これは、アップストリームの非推奨通知の必要性をなくすものではありません（オプションが削除されたときにAPIがすぐに失敗するか、少なくとも警告を発することを望みます）が、スクリプトがサイレントに壊れるリスクを軽減しました。
「いいね！」 4
thoka
(Thomas Kalka)
3
プラグインで独自のAPIエンドポイントを実装するのは、それほど難しくないはずです。その後、通常のRSpecの方法でテストスイートを作成し、アップデート前にステージングサイトで呼び出すことができます。
「いいね！」 1