500 error loading summary page for some users (beta4)

I’m seeing a 500 error loading some users’ summary pages:

NoMethodError (undefined method `attributes' for nil:NilClass) /var/www/discourse/app/models/user_summary.rb:196:in `block in user_counts'

and

/var/www/discourse/app/models/user_summary.rb:196:in `block in user_counts'
/var/www/discourse/app/models/user_summary.rb:194:in `map'
/var/www/discourse/app/models/user_summary.rb:194:in `user_counts'
/var/www/discourse/app/models/user_summary.rb:80:in `most_liked_users'
/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/active_model_serializers- 
0.8.4/lib/active_model/serializer.rb:122:in `block (2 levels) in associate'
...

I haven’t been able to ascertain if there are commonalities between the user profiles this happens to, but perhaps it has to do with which users are most liked by that user.

Happy to get any ideas on how to fix this :slight_smile:

Cheers!

3 Likes

Hmmm I am torn on fixing this @eviltrout

This repros the issue:

  it "is robust enough to handle bad data" do
    UserActionCreator.enable

    liked_post = create_post
    user = Fabricate(:user)
    PostAction.act(user, liked_post, PostActionType.types[:like])

    users = UserSummary.new(user, Guardian.new).most_liked_users

    expect(users.map(&:id)).to eq([liked_post.user_id])

    # really we should not be corrupting stuff like this
    # but in production dbs this can happens sometimes I guess
    liked_post.user.delete

    users = UserSummary.new(user, Guardian.new).most_liked_users
    expect(users).to eq([])

  end

But you should not be doing #delete on users and leaving a mess around.

Simplest workaround is hunting for all the acting_user_id in user_actions table that do not have records in users table and nuking properly.

Since I have not seen this in our logs across 1000 sites I am somewhat reluctant to patch the code to allow for this corruption.

7 Likes

Hi @sam,

I am plagues by the same error. Is there anything I can do to offer you more insight?

OK I guess we hit the rule of 3 here… @vinothkannans can you fix the test case here:

Option 1.

Make our weekly job fix up internal data

Option 2.

Allow this thing to work even if internal data is a bit corrupt


I am tossing and turning between picking 1 or 2 … your call

4 Likes

I recommend whatever is easiest.

1 Like

Then it’s done by the 2nd option :wink:

7 Likes

This topic was automatically closed after 4 days. New replies are no longer allowed.