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

I’ve run into the same kind of breakage, but I went down a different path. Instead of consuming the calendar API endpoints directly, my importer builds [event] BBCode and posts it into Discourse, letting the plugin parse it as if a staff user had created the event by hand. That way I avoid depending on transient query parameters like include_expired, and I get a more stable contract — plain posts and BBCode are unlikely to change without notice.

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Meet to discuss Discourse RESTful API
[/event]

The trade-off is more work on my end: I had to write a formatter that converts ICS data into properly escaped [event] tags, handles all-day versus timed events, and so on. But in practice this approach has been far more resilient across upgrades. It doesn’t remove the need for upstream deprecation notices (I’d still like APIs to fail fast or at least warn when options are removed), yet it has reduced the risk of my scripts breaking silently.

3 likes
3

Implementing your own API endpoint via a plugin shouldn’t be that hard. Then you can use the usual RSpec way for a test suite, which you can call on a staging site before updates.

1 like