Veo lo mismo. Si configuro la cantidad de workers de Puma en 1, el problema desaparece. Parece que cada worker mantiene una copia del objeto de configuración del sitio, y cuando un worker realiza una actualización, los demás workers nunca se enteran de ese cambio.
Desafortunadamente, este problema también está presente en un entorno escalado con múltiples servidores de Discourse, por lo que simplemente establecer la cantidad de workers en 1 no es una solución total.
Estoy intentando hacer desarrollo de plugins, así que seguí el enlace en el README para configurar un entorno de desarrollo en Ubuntu. Cuando ejecuto el comando bundle exec rails server --binding=0.0.0.0, la aplicación se inicia con Puma.
El servidor sigue en ejecución. He verificado en los registros que Discourse está atendiendo la solicitud. Además, tengo la caché desactivada en la consola de desarrollador de mi navegador mientras depuro esto.
¿Por qué estás escalando horizontalmente durante el desarrollo de complementos?
Los síntomas indican que tu MessageBus interno está roto, por lo que algo va mal con tu configuración de Redis. Las actualizaciones en vivo en el navegador también podrían estar rotas.
No estaba escalando para el desarrollo de complementos, solo probando esto en varios escenarios diferentes para intentar reducir mi problema y asegurarme de haberlo entendido. Si se supone que MessageBus debe manejar esto, lo investigaré más a fondo.
Mientras depuraba, noté que app/models/site_setting.rb aún está disparando un evento :site_setting_saved, el cual parece haber sido eliminado de la aplicación y reemplazado por :site_setting_changed. Ya no hay nada escuchando el evento :site_setting_saved.