Wrong account avatar after upgrade

Hello,

I just upgraded to 1.9.0.beta14 (I had to rebuild app)
After upgrading I enabled https by editing the app.yaml and rebuilt app again (Let’s Encrypt)

Now I have this weird bug, one of the account’s avatar’s is showing that of another, constantly.

user A has the avatar of user B
user B however still has their correct avatar.

How to solve this?

2 Likes

I am also seeing issues with this on my forum after upgrading to latest this morning, just noticed it a little bit ago.

It seems like I am seeing the correct avatar:

  • Within a topic
  • On user cards
  • On individual profile pages

But I am seeing incorrect avatars:

  • On /latest
  • On admin/users
  • On my profile button (top right corner of the screen)

I am also occasionally seeing a gray placeholder avatar thing, but I haven’t narrowed down when exactly it’s showing up…

I am also using https via Let’s Encrypt, and have been for a fair amount of time now (months? I dunno), in case that’s relevant.

I also have this error in /logs (42 times as of now), which I haven’t seen before:

Failed to process hijacked response correctly undefined method ‘upcase’ for nil:NilClass

/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/logster-1.2.8/lib/logster/logger.rb:93:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/logster-1.2.8/lib/logster/logger.rb:50:in `add'
/usr/local/lib/ruby/2.4.0/logger.rb:534:in `warn'
/var/www/discourse/lib/hijack.rb:32:in `rescue in block in hijack'
/var/www/discourse/lib/hijack.rb:29:in `block in hijack'
/var/www/discourse/lib/scheduler/defer.rb:74:in `block in do_work'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rails_multisite-1.1.2/lib/rails_multisite/connection_management.rb:77:in `with_connection'
/var/www/discourse/lib/scheduler/defer.rb:72:in `do_work'
/var/www/discourse/lib/scheduler/defer.rb:61:in `block (2 levels) in start_thread'
2 Likes

Hijack sounds like what @sam was working on…

1 Like

Do you have more of a stack trace there, try looking at all tabs, try visiting the error page

The only additional info I didn’t include was from the env tab:

hostname	sih-app
process_id	[29461, 29445, 29367, 29351]
application_version	[87ada55e677416713f24912487cde48221467b4d, c22f202e10dd70597f0e1afbd81b39f3b4f4e9c9]

Those 9 lines are all I see in the backtrace, though.

Can anonymous users see shared logs? Just in case, link to the shared log on my forums. Nope, sure can’t.

Actually … I just reproduced the issue … will get it fixed asap.

5 Likes

To answer your question while Sam fixes the bug: no.

1 Like

Yeah I just did some stellar detective work (logged out of my forums and clicked the link) to find that out myself. :blush:

Thanks for looking into this @sam!

1 Like

Alternatively, you could just open a new incognito window in your favorite browser :wink:

1 Like

Ugh this is a nasty bug any eta on fix @sam?

Will be fixed in 3 hours, probably sooner.

1 Like

This should fix it, but if anything is cached on the CDN in incorrectly … I can not flush that.

4 Likes

Is it looking correct now @Yuun ?

The avatars look correct on my current browser, but I’m getting a long list of Failed to load resource: the server responded with a status of 500 () in my Chrome error log right now for each avatar it’s trying to load.

1 Like

Yeah I can see that, fixing.

Fixed per:

4 Likes

Hm, still getting the 500 errors on avatar load after updating to this commit.

Nevermind, appears to have stopped now. Browser cache thing?

Yeah was cached super aggressively.

This topic was automatically closed after 29 hours. New replies are no longer allowed.