Can't nominate admins or moderators due to import

(Cy) #1


I have a problem with “set administrator/moderator” buttons that when I try to nominate a user for that i get:

ActiveRecord::RecordInvalid (Validation failed: Name has already been taken)

Any idea why and how could I solve this? Many thanks

(Régis Hanol) #2

Seems like you have 2 users with the same username (which might happen after an import depending on what validations you disabled).

(Cy) #3

It happens with all the users I try to nominate as mods or admins.

Do I understand correctly that 1 dupped user could cause that problem? If so could you please suggest a way of proceeding to solve the issue?

Many thanks @zogstrip

(Cy) #4

I’ve run:

[17] pry(main)>"count(*) > 1")
=> []

and as you can see there seems not to be dupped users… Any hint @zogstrip zog?

(Cy) #5

I can’t seem to be able to solve this. Do you have any hints I would go for? Any help is really appreciated.

(Sam Saffron) #6

What is the backtrace?

(Cy) #7

I did a big import from vbulleting with about 60k users and 1M posts. Nothing else installed or hacked. Running on a Docker install. Is that what you’re asking @sam?

(Sam Saffron) #8

If you look in /logs there is a tab for a backtrace so we can see where this is coming from.

(Cy) #9

Thank you @sam and apologies and am still familiarising with terminology:

Here is the backtrace < Recent Message ActiveRecord::RecordInvalid (Error en la validación: Name -

(Cy) #10

Have you had a chance to look at it @sam ? I can’t figure out anything clear from that log

(Manthan Mallikarjun) #11

ActiveRecord::RecordInvalid (Error en la validación: Name ya ha sido escogido)Share Protect

Error en la validación: Name ya ha sido escogido in english means Validation failed: Name has already been chosen. @zogstrip is right. It looks like there are two users with the same username.

(Cy) #12

That’s what it seems but how if you see post #4, the query returns nil. How could I identify that dupped user? Additionally if you keep reading, this error happens for EVERY SINGLE USER I try to get nominated

(Manthan Mallikarjun) #13

Maybe the SQL statement is wrong? I have no idea. Sorry.

(Cy) #14

Maybe it’s better then not to reply to the topic?

(Jeff Atwood) #15

This whole topic is a cluster, because it is a failed import. Who knows what state your database is in.

(Cy) #16

The import didn’t through any errors so I assume it wasn’t corrupted. The forum is up and running. Everyone is happy except for that only bit.

It there any way to run a consitancy check and repair whatever is broken then?

(Kane York) #17

Nobody ever built that, because we never needed to. ActiveRecord is doing on-the-fly consistency checks as the data is accessed, and it seems the checks are failing.

(Cy) #18

That’s correct. Even if I trigger manually the DBCONSISTENCYCHECK at the sidekiq scheduler and it’s the only “FAILED”

I must say that I didn’t hack anything in special at the import script or forum, so I wonder how that corruption could happen and if it happened to other people too that uses the same import script (bundled in)

(Cy) #19

Is there anyone with enough knowledge on this? I am happy to pay for this service and also I’d contribute the fix to the community.

Many thanks

(Cy) #20

As an update, I could manually enable their admins with:

u = User.find_by_email("")   <-- I also tried and worked with find_by_username
u.moderator = true

The curious thing is that the DB nor the command line didn’t complained at all??

When I trigger the EnsureDBConsistency job I get this backtrace:

/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/validations.rb:57:in `save!'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/attribute_methods/dirty.rb:29:in `save!'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/transactions.rb:273:in `block in save!'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/transactions.rb:329:in `block in with_transaction_returning_status'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/connection_adapters/abstract/database_statements.rb:201:in `block in transaction'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/connection_adapters/abstract/database_statements.rb:209:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/connection_adapters/abstract/database_statements.rb:201:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/transactions.rb:208:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/transactions.rb:326:in `with_transaction_returning_status'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/transactions.rb:273:in `save!'
/var/www/discourse/app/models/group.rb:136:in `refresh_automatic_group!'
/var/www/discourse/app/models/group.rb:149:in `block in refresh_automatic_groups!'
/var/www/discourse/app/models/group.rb:148:in `each'
/var/www/discourse/app/models/group.rb:148:in `refresh_automatic_groups!'
/var/www/discourse/app/jobs/scheduled/ensure_db_consistency.rb:8:in `execute'
/var/www/discourse/app/jobs/base.rb:153:in `block (2 levels) in perform'