¿Proceso de cambio de API?

[dubwoc]

He estado ejecutando algunos sitios de Discourse durante algún tiempo y tengo una serie de scripts que interactúan directamente con algunas de las API de Discourse y descubro que periódicamente las cosas dejan de funcionar después de una actualización. Generalmente, esto está bien si las cosas son detectables de inmediato, pero cuando no aparecen durante un tiempo, se vuelve difícil de solucionar y, a menudo, resulta en problemas de producción en lugar de instancias de desarrollo.

Por ejemplo: Recurring events in Upcoming Events calendar fail to handle daylight saving change

Recientemente eliminé la opción include_expired, desafortunadamente el comportamiento de solo tener eventos devueltos desde la API del calendario que no han expirado era algo en lo que confiaba y causó que una serie de procesos fallaran en una fecha posterior a la actualización. Para este ejemplo en particular, fallar si un llamador especificaba el parámetro ahora eliminado al menos habría detenido el problema en mi script particular

Entonces, lo que me pregunto es, como usuario posterior de Discourse, ¿cuál es la mejor manera de identificar cambios en la API como este antes de que lleguen a mi instancia? Anteriormente recurrí a duplicar el repositorio de discourse-calendar y actualizarlo con menos frecuencia en mi propio tiempo para evitar estos problemas, ahora que está integrado decidí abandonar ese enfoque y me está volviendo a morder.

Agradezco todo el trabajo y la mejora que Discourse experimenta constantemente y estoy bien si la respuesta es “regístrate para obtener la versión empresarial y estas cosas sucederán con menos frecuencia”, o agrega más pruebas de tu parte, pero quería ver si tal vez hay otras opciones o enfoques de los que no soy consciente.

Gracias.

[Ethsim2 (Ethan)]

He encontrado el mismo tipo de problema, pero he seguido un camino diferente. En lugar de consumir directamente los puntos finales de la API del calendario, mi importador crea BBCode de [event] y lo publica en Discourse, permitiendo que el plugin lo analice como si un usuario administrador hubiera creado el evento manualmente. De esa manera, evito depender de parámetros de consulta transitorios como include_expired, y obtengo un contrato más estable: las publicaciones y el BBCode simples es poco probable que cambien sin previo aviso.

[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Reunión para discutir la API RESTful de Discourse
[/event]

La contrapartida es más trabajo de mi parte: tuve que escribir un formateador que convierte los datos ICS en etiquetas [event] debidamente escapadas, maneja eventos de todo el día o programados, etc. Pero en la práctica, este enfoque ha sido mucho más resistente a las actualizaciones. No elimina la necesidad de avisos de desaprobación previos (todavía me gustaría que las API fallaran rápidamente o al menos advirtieran cuando se eliminan opciones), sin embargo, ha reducido el riesgo de que mis scripts se rompan silenciosamente.

[thoka (Thomas Kalka)]

Implementar tu propio endpoint de API a través de un plugin no debería ser tan difícil. Luego puedes usar la forma habitual de RSpec para un conjunto de pruebas, que puedes llamar en un sitio de staging antes de las actualizaciones.