Rake users:merge on former admin account throws error

A former admin has left the company and I am trying to merge his old account into his personal account and encountering errors:

rake users:merge['source','target']

rake aborted!

ArgumentError: ArgumentError

/var/www/discourse/app/services/post_owner_changer.rb:10:in `initialize'
/var/www/discourse/app/services/user_merger.rb:60:in `new'
/var/www/discourse/app/services/user_merger.rb:60:in `change_post_owner'
/var/www/discourse/app/services/user_merger.rb:48:in `block in move_posts'
/var/www/discourse/app/services/user_merger.rb:46:in `each'
/var/www/discourse/app/services/user_merger.rb:46:in `move_posts'
/var/www/discourse/app/services/user_merger.rb:11:in `merge!'
/var/www/discourse/lib/tasks/users.rake:48:in `block in <top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'

Tasks: TOP => users:merge
(See full trace by running task with --trace)
1 Like

This suggests that the users could not be found.

Did you enter the command exactly like this? You need to replace ‘source’ and ‘target’ with the appropriate usernames.

That would produce another error by the rake task:

“ERROR: User with username source does not exist”

To me it looks like the database is corrupt and contains posts with topic ids of non-existent topics.

1 Like

i don’t think this is a corrupt database per se. I have seen many kind-of-legit cases where changing post ownership fails , especially where the destination user has less privileges than the original user.


I replaced the arguments that are sensitive with placeholders ‘source’, ‘target’. I don’t believe the database is corrupt as it would bring on a whole new slew of issues but is there any way I can check off hand?

This would definitely be the case as we are merging a previous admin account into a basic user account.

Further more, I removed all admin abilities and mod privileges and tried to merge the accounts again with no success.


You can run the following code in the rails console (rails c) to find the offending posts. I’ll leave it up to you what you do with them.

source_user = User.find_by_username("<source username>");

  where(user_id: source_user.id).
  where("NOT EXISTS (SELECT 1 FROM topics WHERE posts.topic_id = topics.id)")

Hey there, what in the returned error leads you to suspect the source username is the source of the issues? Just trying to understand better. Thanks!

1 Like

Because it fails in line 10 of post_owner_changer.rb (this is where posts are moved from the source to the target user) and the only object that can be nil at that place is @topic. That leads me to believe that you have at least one post with a topic_id that points to a missing topic in the database.


Looking at this here with @Jim.Morrison and it’s listing out some topic IDs which pull up “Ooops! That page doesn’t exist or is private”… We did a migration with @pfaffman about a year ago and I am wondering if some of these are a result of that? Do we just need to do a rake task that can be run to rebuild / remap titles?


I suggest you either delete the posts via PostDestroyer.new(Discourse.system_user, post).destroy or update the topic_id with the ID of a new topic. You’d also need to make sure that the post_number is unique in that topic.
Deleting is probably easier and I guess you don’t need them otherwise you’d have missed them already. :wink:

1 Like

My guess is that some of the posts are in topics that only an admin can write and or read. He won’t be able to access those posts if he is not an admin.

You might be able to do it the other way.

Merge the non admin account into the admin account, then rename the admin account to the non admin account, then remove the admin privileges.

He will still get “Oops” on topics in categories that he no longer has access to.


If a topic can be moved to an area that the users can’t see why would it fail when re-attributing posts?

No, it’s definitely a missing topic. There are no security checks in database queries! My guess is that someone deleted one or more topics from the database without deleting all the stuff connected to it.


The ones that we saw were old enough that they likely were part of the database import we did from AnswerHub and can likely be deleted.

This is what ended up being the successful approach for our use-case. Thank you everyone for your input :pray:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.