Oui, nous avons commencé à remarquer ce problème d’avatar personnalisé bien après que le processus sidekiq ait eu le temps de reconstruire toutes les images d’avatar et de profil annexes, mais uniquement avec la configuration utilisant un proxy inverse nginx vers un socket Unix.
Les petites icônes d’avatar fonctionnent correctement ; mais elles ne s’affichent pas dans la carte de profil ni sur les pages de profil (sauf si elles étaient mises en cache auparavant et que le cache n’a pas expiré).
Dès que nous exécutons :
nginx -s stop; ./launcher start web-only
Le problème des images d’avatar personnalisées disparaît (pour les images qui n’ont pas encore été consultées / mises en cache dans le navigateur).
Et dès que nous exécutons ensuite :
./launcher stop web-only; nginx
Le problème des images d’avatar personnalisées réapparaît pour les images qui n’ont pas encore été consultées / mises en cache.
Il n’y a aucune erreur avec HTTPS et ce problème n’est absolument pas lié à force_https (sans rapport) :
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)
Nous avons confirmé ce problème sur mobile (iOS, dernière version), sur ordinateur de bureau, dans Chrome (dernière version), dans Safari (dernière version), etc.
Quelque chose d’étrange se produit lors de l’utilisation de nginx comme proxy inverse vers un socket Unix, ce qui affecte les images d’avatar personnalisées.
Pour l’instant, désolé de vous l’annoncer @ariznaf, nous n’avons pas réussi à isoler le problème et nous n’avons pas encore de solution.
On a l’impression que, dans la configuration proxy inverse nginx vers un socket Unix, l’application Discourse (le conteneur) ne reconstruit pas ces images d’avatar personnalisées comme elle le fait dans la configuration sans nginx en tant que proxy inverse vers un socket Unix.
Peut-être que sidekiq n’apprécie pas la configuration proxy inverse nginx vers un socket Unix et refuse de planifier ou d’exécuter ce processus de reconstruction, LOL ? @riking ?
Étrange.