API-Änderungsprozess?

[dubwoc]

Ich betreibe seit einiger Zeit einige Discourse-Sites und habe eine Reihe von Skripten, die direkt mit einigen der Discourse-APIs interagieren. Ich stelle fest, dass die Dinge nach einem Upgrade periodisch nicht mehr funktionieren. Das ist im Allgemeinen in Ordnung, wenn die Dinge sofort erkennbar sind, aber wenn sie erst nach einiger Zeit auftreten, wird es schwierig, sie zu beheben, und führt oft zu Produktionsproblemen anstelle von Entwicklungsinstanzen.

Zum Beispiel: Recurring events in Upcoming Events calendar fail to handle daylight saving change

Kürzlich wurde die Option include_expired entfernt. Leider war das Verhalten, dass nur nicht abgelaufene Ereignisse von der Kalender-API zurückgegeben wurden, etwas, auf das ich mich verlassen habe, und es führte dazu, dass eine Reihe von Prozessen zu einem späteren Zeitpunkt nach dem Upgrade fehlschlugen. Für dieses spezielle Beispiel hätte das Fehlschlagen, wenn ein Aufrufer den jetzt entfernten Parameter angegeben hätte, das Problem in meinem speziellen Skript zumindest gestoppt

Daher frage ich mich, was als nachgelagerter Benutzer von Discourse der beste Weg ist, API-Änderungen wie diese zu identifizieren, bevor sie meine Instanz erreichen? Zuvor habe ich das discourse-calendar-Repository gespiegelt und es seltener auf eigene Kosten aktualisiert, um diese Probleme zu vermeiden. Da es jetzt integriert ist, habe ich beschlossen, diesen Ansatz aufzugeben, und werde wieder gebissen.

Ich schätze die ganze Arbeit und die ständigen Verbesserungen, die Discourse erfährt, und es ist in Ordnung für mich, wenn die Antwort lautet: “Melden Sie sich für Enterprise an, und diese Dinge werden seltener passieren” oder “Fügen Sie mehr Tests auf Ihrer Seite hinzu”, aber ich wollte sehen, ob es vielleicht andere Optionen oder Ansätze gibt, die ich nicht kenne.

Vielen Dank.

[Ethsim2 (Ethan)]

Ich bin auf die gleiche Art von Problemen gestoßen, aber ich bin einen anderen Weg gegangen. Anstatt die Kalender-API-Endpunkte direkt zu nutzen, erstellt mein Importer [event] BBCode und postet ihn in Discourse, sodass das Plugin ihn so parst, als hätte ein Mitarbeiter das Ereignis von Hand erstellt. Auf diese Weise vermeide ich die Abhängigkeit von transienten Abfrageparametern wie include_expired und erhalte einen stabileren Vertrag – einfache Posts und BBCode werden sich wahrscheinlich nicht ohne Vorankündigung ändern.

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Treffen zur Besprechung der Discourse RESTful API
[/event]

Der Kompromiss ist mehr Arbeit meinerseits: Ich musste einen Formatter schreiben, der ICS-Daten in ordnungsgemäß maskierte [event]-Tags umwandelt, ganztägige oder zeitlich festgelegte Ereignisse behandelt und so weiter. Aber in der Praxis war dieser Ansatz bei Upgrades weitaus widerstandsfähiger. Er beseitigt nicht die Notwendigkeit von Upstream-Deprecation-Hinweisen (ich möchte immer noch, dass APIs schnell fehlschlagen oder zumindest warnen, wenn Optionen entfernt werden), aber er hat das Risiko verringert, dass meine Skripte stillschweigend kaputtgehen.

[thoka (Thomas Kalka)]

Das Implementieren eines eigenen API-Endpunkts über ein Plugin sollte nicht so schwer sein. Dann können Sie die übliche RSpec-Methode für eine Testsuite verwenden, die Sie vor Updates auf einer Staging-Website aufrufen können.