Rails callbacks behaving differently on different environments - ruby-on-rails

Question

I have two Rails environments. One development environment running Postgres and Rails 5.0.6 and an almost identical environment on Heroku.
I have an Administrator class, which generates a username for an Administrator on a before_save callback based on the user's forename and surname fields.
class Administrator < ApplicationRecord
validates :username, uniqueness: true
validates :forename, presence: true
validates :surname, presence: true
before_save :generate_username
def generate_username
return if username.present?
proposed = "#{forename}#{surname}".downcase
existing_count = Administrator.where("username ILIKE ?", "#{proposed}%").size
self.username = existing_count.zero? ? proposed : "#{proposed}#{existing_count}"
end
end
After the user is validated, a username is generated in the form FORENAMESURNAMEX where X is an incrementing number (or nothing).
Here's the commands I run in the Rails console on my development machine.
irb(main):012:0> Administrator.create(email: 'edward#test.net', forename: 'Edward', surname: 'Scissorhands')
D, [2017-10-13T10:00:18.985765 #280] DEBUG -- : (0.2ms) BEGIN
D, [2017-10-13T10:00:18.987554 #280] DEBUG -- : Administrator Exists (0.5ms) SELECT 1 AS one FROM "administrators" WHERE "administrators"."email" = $1 LIMIT $2 [["email", "edward#test.net"], ["LIMIT", 1]]
D, [2017-10-13T10:00:18.988923 #280] DEBUG -- : Administrator Exists (0.4ms) SELECT 1 AS one FROM "administrators" WHERE "administrators"."username" IS NULL LIMIT $1 [["LIMIT", 1]]
D, [2017-10-13T10:00:18.990155 #280] DEBUG -- : (0.4ms) SELECT COUNT(*) FROM "administrators" WHERE (username ILIKE 'edwardscissorhands%')
D, [2017-10-13T10:00:18.992000 #280] DEBUG -- : SQL (0.5ms) INSERT INTO "administrators" ("email", "created_at", "updated_at", "username", "forename", "surname") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id" [["email", "edward#test.net"], ["created_at", "2017-10-13 10:00:18.990421"], ["updated_at", "2017-10-13 10:00:18.990421"], ["username", "edwardscissorhands"], ["forename", "Edward"], ["surname", "Scissorhands"]]
D, [2017-10-13T10:00:18.995845 #280] DEBUG -- : (1.8ms) COMMIT
=> #<Administrator id: 10, email: "edward#test.net", created_at: "2017-10-13 10:00:18", updated_at: "2017-10-13 10:00:18", role: nil, otp_public_key: nil, username: "edwardscissorhands", forename: "Edward", surname: "Scissorhands">
As you can see, the callback is executed and the user's username is generated and persisted to the database as expected.
However, when I run the same code on a our test environment running on Heroku (and Heroku Postgres), this is what happens:
irb(main):005:0> Administrator.create!(email: 'edward#test.net', forename: 'Edward', surname: 'Scissorhands')
(1.9ms) BEGIN
Administrator Exists (1.1ms) SELECT 1 AS one FROM "administrators" WHERE "administrators"."email" = $1 LIMIT $2 [["email", "edward#test.net"], ["LIMIT", 1]]
Administrator Exists (0.9ms) SELECT 1 AS one FROM "administrators" WHERE "administrators"."username" IS NULL LIMIT $1 [["LIMIT", 1]]
(0.9ms) ROLLBACK
ActiveRecord::RecordInvalid: Validation failed: Username has already been taken
(I'm using create! here instead of create to show the validation errors that do not occur in development.)
I don't see why the behaviour should differ between environments. Both are running identical versions of Rails (5.0.6) and are running identical codebases.

Answer 1

before_save is called after validation, hence the error.
Try before_validation instead.
For reference here's the order callbacks are called when creating an object:
before_validation
after_validation
before_save
around_save
before_create
around_create
after_create
after_save
after_commit/after_rollback

Answer 2

The logic in your code is flawed. This is a legitimate bug; you need to redesign how username generation words.
For example, suppose there is one user in your system called: edwardscissorhands1. There is no edwardscissorhands, and no edwardscissorhands2/3/4 etc.
The line: Administrator.where("username ILIKE ?", "edwardscissorhands%").size returns 1, and then your logic tries to create a new user that already exists.
... I cannot say for sure what has happened on your production server without seeing the actual data, but I bet it's something like this. It could be slightly more convoluted, e.g. the users: tom, tom3 and tomlord exist; therefore your logic tries to create a second tom3 user.
For example, this might have happened if you generated some edwardscissorhards users, then deleted one or more of them.
As an example, here's one way you could redesign the logic:
def generate_username
return if username.present?
proposed = "#{forename}#{surname}".downcase
return proposed unless Administrator.exists?("username ILIKE ?", proposed)
counter = 1
while(Administrator.exists?("username ILIKE ?", "#{proposed}#{counter}"))
counter += 1
end
"#{proposed}#{counter}"
end
This could probably be improved performance-wise, although the multiple database queries here are unlikely to be a major issue in the real application (assuming you don't get lots of administrators with the same name!).