Yes, we starting seeing this custom avatar problem again long after the sidekiq process had time to rebuild any adjunct avatar and profile images, but only on the configuration with the nginx reverse proxy to a unix domain socket.
The small icon avatars are fine; but they don’t work in profile card or in the profile pages (unless they were cached before and the cache has not expired).
As soon as we do this:
nginx -s stop; ./launcher start web-only
The problem with the custom avatar images goes away (on images not previously viewed / cached in the browser).
and as soon after we do this:
./launcher stop web-only; nginx
The problem with the custom avatar images returns for images not yet views / cached.
There are no errors with HTTPS and this is definitely not because of force_https (totally 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)
We have confirmed this issue on mobile (ios, latest version), on desktop, in chrome (latest), in safari (latest), etc.
There is something odd which happens using the ngnix as a reverse proxy to a unix socket which effects the custom avatar images.
So far, sorry to inform @ariznaf, we cannot isolate the problem and don’t have a solution.
It “feels like” that in the nginx reverse proxy to a unix socket config, the discourse app (the container) is not rebuilding these custom avatar images like they do in the config without nginx as a reverse proxy to a unix domain socket.
Maybe sidekiq does not like the nginx reverse proxy to unix socket config and refuses to schedule or run this rebuilding process, LOL ? @riking ?
Strange.