I’ve been racking my brains around why I’ve got lots of “generic heads avatars” but the UpdateGravatar job was not updating the UserAvatar yet not logging ANYTHING… I managed to track it down to:
if tempfile
upload = UploadCreator.new(tempfile, 'gravatar.png', origin: gravatar_url, type: "avatar").create_for(user_id)
if gravatar_upload_id != upload.id
gravatar_upload&.destroy!
self.gravatar_upload = upload
save!
end
end
UploadCreator returns the id for the extant file if the gravatar hasn’t changed, so we just abort.
BUT:
[46] pry(main)> Upload.find(3)
=> #<Upload:0x0000561fc5b5b8d8
id: 3,
user_id: 1,
original_filename: "gravatar.png",
filesize: 166131,
width: 360,
height: 360,
url: "/uploads/default/original/1X/0430db64b0848c22047072b62e52bf733b105010.png",
created_at: Wed, 01 Aug 2018 19:06:17 UTC +00:00,
updated_at: Wed, 01 Aug 2018 19:06:17 UTC +00:00,
sha1: "0430db64b0848c22047072b62e52bf733b105010",
origin: "https://www.gravatar.com/avatar/e8b7922236865bfc10fb22eb13f9c394.png?s=360&d=404",
retain_hours: nil,
this looks all well and good until you realize I’m working in the but the upload record is pointing at the load filesystem instead of the . So the whole time, Discourse can’t read the file but the update job won’t put a new one into place.
As for how it got into this state in the first place, that’s something else I’m investigating.
Perhaps nothing needs to change in the UpdateGravatar job itself, perhaps something should be done to recover from this state when retrieving the user avatar (e.g. invalidating the upload)… or maybe this is an UploadCreator bug and it should be verifying the existing upload.is accessible rather than assuming.
I bet that would fix… Other things