Ja, wir haben dieses Problem mit benutzerdefinierten Avataren wieder bemerkt, lange nachdem der sidekiq-Prozess Zeit hatte, alle zugehörigen Avatar- und Profilbilder neu zu erstellen. Dies tritt jedoch nur bei der Konfiguration mit dem nginx Reverse Proxy für einen Unix-Domain-Socket auf.
Die kleinen Icon-Avatare funktionieren einwandfrei; sie werden jedoch in der Profil-Karte oder auf den Profilseiten nicht angezeigt (es sei denn, sie wurden bereits zwischengespeichert und der Cache ist noch nicht abgelaufen).
Sobald wir Folgendes ausführen:
nginx -s stop; ./launcher start web-only
verschwindet das Problem mit den benutzerdefinierten Avatarbildern (bei Bildern, die zuvor noch nicht im Browser angesehen oder zwischengespeichert wurden).
Und sobald wir danach Folgendes tun:
./launcher stop web-only; nginx
kehrt das Problem mit den benutzerdefinierten Avatarbildern für Bilder zurück, die noch nicht angesehen oder zwischengespeichert wurden.
Es gibt keine Fehler mit HTTPS, und dies liegt definitiv nicht an force_https (völlig unrelated):
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)
Wir haben dieses Problem auf mobilen Geräten (iOS, neueste Version), auf dem Desktop, in Chrome (neueste Version), in Safari (neueste Version) usw. bestätigt.
Es gibt etwas Seltsames, das beim Einsatz von Nginx als Reverse Proxy für einen Unix-Socket auftritt und die benutzerdefinierten Avatarbilder beeinflusst.
Bislang müssen wir @ariznaf leider mitteilen, dass wir das Problem nicht isolieren konnten und keine Lösung haben.
Es „fühlt sich so an“, als würde in der Konfiguration mit nginx Reverse Proxy für einen Unix-Socket die Discourse-App (der Container) diese benutzerdefinierten Avatarbilder nicht neu erstellen, wie es in der Konfiguration ohne Nginx als Reverse Proxy für einen Unix-Domain-Socket der Fall ist.
Vielleicht mag sidekiq die Konfiguration mit nginx Reverse Proxy für einen Unix-Socket nicht und weigert sich, diesen Neukonstruktionsprozess zu planen oder auszuführen, LOL? @riking?
Seltsam.