API-wijzigingsproces?

Ondersteuning
1

I have been running a few discourse sites for some time now and I have a number of scripts that interact directly with some of Discourse’s APIs and I find that periodically things just stop working after an upgrade. Generally this is fine if the things are detectable immediately but when they don’t show up for a bit of time it becomes difficult to chase things down and often results in production issues rather than dev instances.

For example: Recurring events in Upcoming Events calendar fail to handle daylight saving change

Recently removed the include_expired option, unfortunately the behavior of only having events returned from the calendar API that are not expired was something I relied on and it caused a number of processes to blow up at a later date after upgrading. For this particular example failing if a caller specified the now removed parameter would have at least stopped the issue in my particular script :slight_smile:

So what I am wondering is as a downstream user of discourse what is the best way to identify API changes like this before they hit my instance? Previously I resorted to mirroring the discourse-calendar repo and upgrading it less frequently on my own time to avoid these problems, now that it is integrated I decided to drop that approach and I am being bit again.

I appreciate all the work and improvement discourse constantly goes under and I am fine if the answer is “sign up for enterprise and these things will happen less frequently,” or add more testing on your end but I wanted to see if maybe there are other options or approaches I am unaware of.

Thank you.

4 likes
2

Ik ben tegen hetzelfde soort problemen aangelopen, maar ik heb een andere weg ingeslagen. In plaats van direct de kalender-API-endpoints te gebruiken, bouwt mijn importer [event] BBCode en plaatst deze in Discourse, waardoor de plugin het kan parsen alsof een medewerker het evenement handmatig heeft aangemaakt. Zo vermijd ik afhankelijkheid van tijdelijke queryparameters zoals include_expired, en krijg ik een stabieler contract — gewone posts en BBCode zullen waarschijnlijk niet zonder waarschuwing veranderen.

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Ontmoeting om de Discourse RESTful API te bespreken
[/event]

De afweging is meer werk aan mijn kant: ik moest een formatter schrijven die ICS-gegevens omzet in correct ontsnapte [event]-tags, rekening houdend met de hele dag geldende of getimede evenementen, enzovoort. Maar in de praktijk is deze aanpak veel veerkrachtiger gebleken bij upgrades. Het neemt de noodzaak van upstream-verwijderingsaankondigingen niet weg (ik wil nog steeds dat API’s snel falen of op zijn minst waarschuwen wanneer opties worden verwijderd), maar het heeft wel het risico verminderd dat mijn scripts stilzwijgend breken.

4 likes
3

Het implementeren van je eigen API-endpoint via een plugin zou niet zo moeilijk moeten zijn. Vervolgens kun je de gebruikelijke RSpec-manier gebruiken voor een testsuite, die je op een staging-site kunt aanroepen vóór updates.

1 like