It looks like there's something which is causing your user to be immediately updated and resaved (including generation of a new confirmation token) before the registration create
action has finished. Looking at your gist:
- Line 5 shows devise checking for existing users with the email address
- Line 6 shows devise checking whether the confirmation token it has just generated already exists for some other user (obviously they need to be unique)
- Line 9 shows the new user record being inserted into your database
- Line 11 then looks like devise has just generated a new confirmation token and is checking whether this new token is in use already.
- Line 14 then shows updated user details being saved, including this new confirmation token. I notice that there is a tos_accepted_at field which wasn't present in the initial insert in line 9. The unconfirmed_email field has also been set and the confirmation_sent_at field is 1 second later than the one saved in line 9; this is probably just due to the normal :confirmable behaviour, though I'm surprised devise didn't catch the fact that the email address was the same as the existing (unconfirmed) one and not bother.
The question is why did the user get saved twice? It looks like you've added a tos_accepted_at attribute. Is there some code somewhere (an after filter?) resaving the user including this attribute, along with all the others, which then triggers devise's confirmable logic again? Speaking of which, I'm most intrigued that it didn't immediately cause a second email to be sent (with a confirmation token that works), given that the confirmation_sent_at timestamp changes.
I notice that there's some version tracking going on too, judging by other INSERTs, though it doesn't look like that can be interfering.
As an additional sanity check, if you could bludgeon the rails console into encrypting what you expect the confirmation token to be, you'd find that the encrypted version matches the version at line 6 of your gist, which is then overwritten in the db at line 9. I can't try this, because it depends on your rails secret (see Devise::TokenGenerator in devise/toekn_generator.rb). Anyway, not necessary, but would confirm that the original confirmation token is never going to work.
I assume the resend works because it's just the normal case (no double save, no extra tos_accepted_at field etc.)
UPDATE
As discussed in the comments, the problem was indeed the tos_accepted_at attribute. It was being updated using update_attribute()
in an after_create
callback. For reasons which are a bit unclear, this seemed to be dirtying all attributes, so they were all saved as well (update_attribute
also saves all other attributes if they're dirty) and devise generated a new confirmation token as part of this process (though we don't think it should have as the email address hadn't actually changed!). Changing your filter which saved the updated tos_accepted_at
to a before_save
filter instead of after_create
avoided the problem by making sure the user was only saved once, because before_save
obviously happens before that first save as opposed to after_create
which of course happens after the save which inserts the user into the db.