Ghost user causes migration 20171229225929_change_user_project_limit_not_null_and_remove_default to fail due to null projects limit

Summary

Migration fails due to ghost user having a null projects_limit.

Steps to reproduce

Have a ghost user and attempt the above migration.

At this stage I'm not entirely sure what causes this edge case, as we haven't seen this before.

Example Project

What is the current bug behavior?

We get an PG::NotNullViolation: ERROR: column "projects_limit" contains null values during upgrade.

What is the expected correct behavior?

Migration should succeed.

Relevant logs and/or screenshots

bash[migrate gitlab-rails database] (gitlab::database_migrations line 49) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of "bash" "/tmp/chef-script20180226-3080-10yukcu" ----
STDOUT: rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::NotNullViolation: ERROR: column "projects_limit" contains null values
: ALTER TABLE "users" ALTER "projects_limit" SET NOT NULL
/opt/gitlab/embedded/service/gitlab-rails/db/migrate/20171229225929_change_user_project_limit_not_null_and_remove_default.rb:30:in `up'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:50:in `block (3 levels) in <top (required)>'
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `<main>'

Caused by:
ActiveRecord::StatementInvalid: PG::NotNullViolation: ERROR: column "projects_limit" contains null values
: ALTER TABLE "users" ALTER "projects_limit" SET NOT NULL
/opt/gitlab/embedded/service/gitlab-rails/db/migrate/20171229225929_change_user_project_limit_not_null_and_remove_default.rb:30:in `up'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:50:in `block (3 levels) in <top (required)>'
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `<main>'

Caused by:
PG::NotNullViolation: ERROR: column "projects_limit" contains null values
/opt/gitlab/embedded/service/gitlab-rails/db/migrate/20171229225929_change_user_project_limit_not_null_and_remove_default.rb:30:in `up'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:50:in `block (3 levels) in <top (required)>'
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
== 20171229225929 ChangeUserProjectLimitNotNullAndRemoveDefault: migrating ====
-- change_column_null(:users, :projects_limit, false)
STDERR:
---- End output of "bash" "/tmp/chef-script20180226-3080-10yukcu" ----
Ran "bash" "/tmp/chef-script20180226-3080-10yukcu" returned 1

Note the output of the following query:

gitlabhq_production=> select name,projects_limit from users where projects_limit is null;
name | projects_limit
------------+----------------
Ghost User |
(1 row)

Output of checks

Results of GitLab environment info

Results of GitLab application Check

Possible fixes

We can fix this by updating projects_limit to a non-null value, however I suspect this is a bug so opening a dev ticket. Would also like to confirm if it's okay to set the project_limit to a random value, or is it better to set to zero.

Customer issue:

ZD: https://gitlab.zendesk.com/agent/tickets/91662 (Internal Only)