What might cause duplicate user registrations?

Question

We have a site with about 16,000 registered users. I've just discovered there are over 100 duplicate user registrations.

These users have all the same details (username email etc) and have been created at about the same time and have a uid that is just one more than the original.

We are using Email Registration module 7.x-1.3. I've tried duplicating the problem by hitting the submission button multiple times and be creating an identical submission. However, I always get the validation error.

Any suggestions?

Note: we also use Rules and there is a rule triggered by a "After updating an existing user account" event. The rule runs some simple PHP code that adds the users details to a CSV file.

Answer 1

I think that this part of your question is crucial:

... there is a rule triggered by a "After updating an existing user account" event. The rule runs some simple PHP code that adds the users details to a CSV file.

I.e. to (a) understand what's happening and (b) to come up with some type of workaround. Read on for more details ...

Understanding what's happening

Your question seems like a variation of the question 'Why is my rule that reacts on event "After updating an existing user account" firing twice?'. The accepted answer in that question might help to understand your issue (what's causing it) also, ie:

some other module code is calling a user_save on hook_user_update triggering the rules event a second time.

If I was to debug this, I'd disable all contributed modules (except "Rules" and "Entity API") to check if it's indeed a contributed module (I don't expect it to be core). And then re-enable the contributed modules one by one until the issue comes back. As soon as it comes back, you pinpointed the contributed module causing the issue, and you can start working on a possible remedy for that.

Workaround 1

That question also has another answer with a very interesting workaround, with an image which looks like so (a picture is worth more then 1000 words):

Workaround 2

Another workaround to prevent this issue from happening, is to improve your existing rule to make it similar to the rule included in my answer to "How to implement a Rules Condition like [account:last-login] = never?". More specifically:

• Add a Rules Condition like: User does NOT (!!!) have a role with role id = "4".
• Add a Rules Action like: Grant User the role with role id = "4".

So this improvement of your rule will check if the user does not yet have some (designated) role with role id = "4" (adapt to whatever role id that fits your case, and make sure this role is NOT yet granted when activating a new user id). If that's the case, then the user is granted that role. With this improvement to your existing rule, this is what will happen:

• The 1st time your Rules Actions will still be performed (and grants the designated role).
• the 2nd time not ALL of your Rules Conditions will be satisfied (since the designated role was granted before), and therefor your Rules Actions will no longer be performed.

Answer 2

If your PHP code is just adding the details to CSV, there is no point in doubting that rule. However, you can just disable that rule for a while and give it a try again. Also, check if there is another custom/contrib module/code that acts when a user is created.