Project Subscription Plans migration failing in dev environments
Several people are encountering issues with a migration in their dev environments. The failing migration is InsertProjectSubscriptionPlanLimits
from !20063 (diffs)
In my case, and similar to @theoretick experience, I recently reset my database so things should be fresh and in a good state. However, I don't have a default
plan in the plans
table, so the migration fails with:
-- execute("INSERT INTO plan_limits (plan_id, \"ci_project_subscriptions\")\nVALUES\n ((SELECT id FROM plans WHERE name = 'default' LIMIT 1), '2')\nON CONFLICT (plan_id) DO UPDATE SET \"ci_project_subscriptions\" = EXCLUDED.\"ci_project_subscriptions\";\n")
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
PG::NotNullViolation: ERROR: null value in column "plan_id" violates not-null constraint
DETAIL: Failing row contains (2, null, 0, 0, 0, 0, 0, 2).
/Users/dblessing/development/gdk/gitlab/lib/gitlab/database/migration_helpers.rb:1124:in `create_or_update_plan_limit'
/Users/dblessing/development/gdk/gitlab/db/migrate/20200225123228_insert_project_subscriptions_plan_limits.rb:17:in `up'
/Users/dblessing/.rbenv/versions/2.6.5/bin/bundle:23:in `load'
/Users/dblessing/.rbenv/versions/2.6.5/bin/bundle:23:in `<main>'
Caused by:
ActiveRecord::NotNullViolation: PG::NotNullViolation: ERROR: null value in column "plan_id" violates not-null constraint
DETAIL: Failing row contains (2, null, 0, 0, 0, 0, 0, 2).
/Users/dblessing/development/gdk/gitlab/lib/gitlab/database/migration_helpers.rb:1124:in `create_or_update_plan_limit'
/Users/dblessing/development/gdk/gitlab/db/migrate/20200225123228_insert_project_subscriptions_plan_limits.rb:17:in `up'
/Users/dblessing/.rbenv/versions/2.6.5/bin/bundle:23:in `load'
/Users/dblessing/.rbenv/versions/2.6.5/bin/bundle:23:in `<main>'
Caused by:
PG::NotNullViolation: ERROR: null value in column "plan_id" violates not-null constraint
DETAIL: Failing row contains (2, null, 0, 0, 0, 0, 0, 2).
/Users/dblessing/development/gdk/gitlab/lib/gitlab/database/migration_helpers.rb:1124:in `create_or_update_plan_limit'
/Users/dblessing/development/gdk/gitlab/db/migrate/20200225123228_insert_project_subscriptions_plan_limits.rb:17:in `up'
/Users/dblessing/.rbenv/versions/2.6.5/bin/bundle:23:in `load'
/Users/dblessing/.rbenv/versions/2.6.5/bin/bundle:23:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
If I manually add the default
plan, or execute rake db:migrate:redo VERSION=20191023152913
then the migrations work correctly.
I also wonder if we should avoid differentiating between .com and self-managed and make the migrations add plan limits for any plan that exists in the database. My dev environment has .com plans in it because I need them for testing .com licensed features. As the migration is written, the other plans in the database won't get the corresponding plan_limits
updates.
Hopefully this only affects dev environments and not production envs. @theoretick mentions maybe we just need to update seeds so this migration will work correctly.
Slack conversation https://gitlab.slack.com/archives/C02PF508L/p1583514551314200 (All relevant details captured in this issue. Just cross-linking the Slack conversation for posterity)