Nodebb: Image caching issues

[sandratatarevicova]

Summary

Several users of our NodeBB forum have reported issues with changing their profile images. The reported scenario is usually as follows.

1. User changes profile image.
2. User logs on a different device.
3. NodeBB still displays the old image.

Environment description

We have several NodeBB containers. Each container runs NodeBB and Nginx used as a proxy. For performance reasons, Nginx caches all images in ^/assets/(uploads/.+/.+\.(?:gif|jpe?g|png)).

Profile images on most pages are served from ${NODEBB_BASE_URL}/assets/uploads/profile/${ID}-profileavatar.png. The URL does not change when a user changes the image, which causes issues with caching. When a user changes the profile image, the new image on the profile edit page is loaded from ${NODEBB_BASE_URL}/assets/uploads/profile/${ID}-profileavatar.png?${TIMESTAMP}. The URL on the profile edit page contains a timestamp in the query string, which causes that

• the new image is loaded on the server side in Nginx, but only on single NodeBB container, which means that all the other containers still serve the old image.
• the new image is loaded in the client's browser, but only in the browser from where the user changed the image. I did not test this case, but I think that when the user uses a different browser, it will still use the old locally cached image if it was previously cached - and this will happen in standard NodeBB setup (even without the caching proxy).

[oplik0]

Actually, I believe this can already be solved by using Keep old versions of avatars and profile covers on the server - this adds the timestamp directly to the avatar filename, meaning the URL is now unique for a new avatar and therefore the file is not retrieved from the cache for everyone.
If I remember from similar issue some time ago the argument for keeping it the way it is now (replace with same filename or change filename but don't delete old ones) was that storage is cheap and most avatars are small images (or at least should be), so it shouldn't present an issue.

However, since this problem appears here again, perhaps it might be worth it to reevaluate this approach?
I'm actually not sure if NodeBB has this type of input, but splitting Keep old versions of avatars and profile covers on the server into Add timestamp to avatars and profile covers filenames and the current Keep old versions of avatars and profile covers on the server, where the second one would require the first one to be enabled, would make the experience a bit better.
It would require additional optional step in User.uploadCroppedPicture (if Add timestamp to avatars and profile covers filenames is enabled, but Keep old versions of avatars and profile covers on the server is disabled, this function would need to delete the previous avatar file), but it would probably help people who want to keep the cache busting, but don't want to keep old files because of it.

An alternative, perhaps, would be to add a query string (with timestamp) to profile image url in user object (uploadedpicture and picture) already - I don't think server needs to access these files directly from the filesystem, so it shouldn't cause any problems with the value there not being valid file paths. Since this is the value used for the buildAvatar, it would add the cache busting query string for everyone.

[barisusakli]

2 settings makes sense I think and it should fix this problem

[barisusakli]

Or we can always add the timestamp and if keep old versions is turned off delete the old image. Dont need a new setting in that case. 🤔