Wrong account avatar after upgrade

(Fouad Farah) #1


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?

Upstream prematurely closed connection
(Sam) #2

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'

(Joshua Rosenfeld) #3

Hijack sounds like what @sam was working on…

(Sam Saffron) #4

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

(Sam) #5

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.

(Sam Saffron) #6

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

(Joshua Rosenfeld) #7

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

(Sam) #8

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!

(Régis Hanol) #9

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

(Jeff Atwood) #10

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

(Sam Saffron) #11

Will be fixed in 3 hours, probably sooner.

(Sam Saffron) #12

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

(Sam Saffron) #13

Is it looking correct now @Yuun ?

(Sam) #14

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.

(Sam Saffron) #15

Yeah I can see that, fixing.

Fixed per:

(Sam) #16

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

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

(Sam Saffron) #17

Yeah was cached super aggressively.

(Sam Saffron) closed #18

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