Vedo la stessa cosa. Se imposto il numero di worker di Puma a 1, il problema scompare. Sembra che ogni worker mantenga una copia dell’oggetto delle impostazioni del sito e, quando un worker esegue un aggiornamento, gli altri worker non ne vengono mai a conoscenza.
Sfortunatamente, questo problema è presente anche in un ambiente scalato orizzontalmente con più server Discourse, quindi impostare semplicemente il numero di worker a 1 non risolve completamente il problema.
Sto cercando di sviluppare un plugin, quindi ho seguito il link nel README per configurare un ambiente di sviluppo su Ubuntu. Quando eseguo il comando bundle exec rails server --binding=0.0.0.0, l’app viene avviata con Puma.
Il server è ancora in esecuzione. Ho verificato dai log che Discourse sta gestendo la richiesta. Inoltre, ho disabilitato la cache nella console degli strumenti per sviluppatori del browser mentre sto effettuando il debug di questo problema.
Perché stai scalando orizzontalmente durante lo sviluppo di plugin?
I sintomi indicano che il tuo MessageBus interno è rotto, quindi c’è qualcosa di sbagliato nella configurazione di Redis. Anche gli aggiornamenti in tempo reale nel browser potrebbero non funzionare.
Non stavo scalando per lo sviluppo di plugin, stavo solo testando questo in diversi scenari per cercare di restringere il campo del mio problema e assicurarmi di averlo capito. Se il MessageBus è tenuto a gestire questo, allora approfondirò l’argomento.
Durante il debug, ho notato che app/models/site_setting.rb sta ancora attivando un evento :site_setting_saved, che sembra essere stato rimosso dall’app e sostituito con :site_setting_changed. Non c’è più nulla in ascolto dell’evento :site_setting_saved.