Issue with admin_detailed_user_serializer

Support
1

Hello,

I’m having an issue with the admin_detailed_user_serializer that is causing 500 Errors when an administrator tries to view a user from the user search. The 500 Error is also happening when making GET api calls to https://mycommunity/admin/users/2000020409.json. Below is the exception from the logs. About 50% of the users are having this error. I tried comparing working verses non working users in the database but I can’t figure out what the issue could be. I suspect that something I did during a user migration from another system caused this problem.

Below were my data migration steps:

  1. Manually inserted data in the users, user_profiles, user_emails and user_stats tables.
  2. Initially all users had an ‘someid@example.com’ email.
  3. I then update the user_email table for the user to have the correct email.
  4. After this point, I noticed that 50% of these users can’t be viewed from the admin user list. However, if you right click on their name in the profile list, to get the profile card to come up, you can click in there and get to the profile fine. You can make updates on the profile but if you try to make someone and admin you will get the same 500 error that I listed below.

Does someone know what this code is checking for? I’m guessing some users must be missing a critical piece of data that is causing this 500 exception. Does anyone have any guesses? I’m new to Discourse and any advice would be greatly appreciated.

Thank You!

app/serializers/admin_user_list_serializer.rb:95:in `time_read'
(eval):27:in `_fast_attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:468:in `rescue in attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:455:in `attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:480:in `_serializable_hash'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:359:in `serializable_hash'
active_model_serializers (0.8.4) lib/active_model/array_serializer.rb:89:in `block in _serializable_array'
activerecord (7.0.4.3) lib/active_record/relation/delegation.rb:88:in `each'
activerecord (7.0.4.3) lib/active_record/relation/delegation.rb:88:in `each'
active_model_serializers (0.8.4) lib/active_model/array_serializer.rb:79:in `map'
active_model_serializers (0.8.4) lib/active_model/array_serializer.rb:79:in `_serializable_array'
active_model_serializers (0.8.4) lib/active_model/array_serializer.rb:73:in `serializable_array'
active_model_serializers (0.8.4) lib/active_model/array_serializer.rb:53:in `as_json'
app/serializers/admin_detailed_user_serializer.rb:166:in `similar_users'
(eval):72:in `_fast_attributes'
active_model_serializers (0.8.4
2

This probably isn’t helpful, but this sounds like where your problem started. It would have been much better to create those users with Rails so that it could do all of the checks on the data when it creates users.

So maybe that’s the step where you broke things.

Is this site live or is it a test site where you can start over? It will be much easier to not break things than to try to figure out what is broken and then how to fix it.

active_model_serializers (0.8.4) lib/active_model/array_serializer.rb:53:in as_json' app/serializers/admin_detailed_user_serializer.rb:166:in similar_users’
(eval):72:in `_fast_attributes’

Maybe that means that you have users with duplicate email addresses?

Edit: I don’t think that’s it.

What I’d recommend is that you look at discourse/script/import_scripts at main · discourse/discourse · GitHub and find a script to base yours on and use such a script to import the data. Unless you have intimate understanding of Rails and Discourse mucking directly with the database is a recipe for disaster.

1 Like
3

Thank you for the reply, I appreciate it. Unfortunately this is a live production site so I’m looking at alternatives rather than starting over. I did notice that when a user logs in, their profile is fixed and the 500 error message goes away. So I’m trying to figure out what is happening during the login process that fixes the user.

1 Like
4

Is it this? And by logging in they add a value to time_read?

2 Likes
5

Nice work, @JammyDodger! I bet that’s the ticket!

Another thing to look for is an ensure_consistency method in the user model. You could look in the source or just try

u=User.find(123)
u. ensure_consistency!

Or maybe without the !

2 Likes