Sì, abbiamo ricominciato a vedere questo problema con gli avatar personalizzati molto tempo dopo che il processo sidekiq aveva avuto il tempo di ricostruire qualsiasi immagine ausiliaria di avatar e profilo, ma solo nella configurazione con nginx come reverse proxy verso un socket Unix.
Le piccole icone degli avatar sono corrette; tuttavia, non funzionano nella scheda del profilo o nelle pagine del profilo (a meno che non fossero già state memorizzate nella cache prima e la cache non sia ancora scaduta).
Non appena eseguiamo:
nginx -s stop; ./launcher start web-only
Il problema con le immagini degli avatar personalizzati scompare (per le immagini non visualizzate precedentemente / memorizzate nella cache del browser).
E subito dopo aver eseguito:
./launcher stop web-only; nginx
Il problema con le immagini degli avatar personalizzati ricompare per le immagini non ancora visualizzate / memorizzate nella cache.
Non ci sono errori relativi a HTTPS e questo non è assolutamente dovuto a force_https (completamente irrilevante):
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
Abbiamo confermato questo problema su mobile (iOS, versione più recente), su desktop, su Chrome (versione più recente), su Safari (versione più recente), ecc.
C’è qualcosa di strano che si verifica quando si utilizza nginx come reverse proxy verso un socket Unix, il quale influisce sulle immagini degli avatar personalizzati.
Finora, scusa per l’informazione @ariznaf, non siamo riusciti a isolare il problema e non abbiamo una soluzione.
“Sembra” che nella configurazione nginx reverse proxy verso un socket Unix, l’applicazione discourse (il contenitore) non stia ricostruendo queste immagini degli avatar personalizzati come fa nella configurazione senza nginx come reverse proxy verso un socket di dominio Unix.
Forse sidekiq non gradisce la configurazione nginx reverse proxy verso socket Unix e si rifiuta di pianificare o eseguire questo processo di ricostruzione, LOL? @riking?
Strano.