Skip to content

fix(db): drop FKs to removed users table so db:migrate completes#3

Open
gomessguii wants to merge 1 commit intodevelopfrom
fix/attachments-polymorphic-migration-abort
Open

fix(db): drop FKs to removed users table so db:migrate completes#3
gomessguii wants to merge 1 commit intodevelopfrom
fix/attachments-polymorphic-migration-abort

Conversation

@gomessguii
Copy link
Copy Markdown
Member

Summary

  • Seven migrations still referenced a users table that no longer exists in community (removed in 9944be0 when identity moved to evo-auth-service). db:migrate aborted on the first of them (CreateFacebookCommentModerations), blocking MakeAttachmentPolymorphic and leaving attachments stuck with the legacy message_id column. Sidekiq/Puma then crashed with PG::UndefinedColumn: attachments.attachable_id does not exist on any media webhook or contact deletion.
  • Each foreign_key: { to_table: :users } / add_foreign_key …, :users swapped for a plain uuid column (same name, so models keep working) plus manual indexes where the auto-generated ones went away.
  • docker/docker-entrypoint.sh: collapsed the db:create / db:migrate / db:evolution_prepare trio (all masked by 2>/dev/null || true) into a single unmasked bundle exec rails db:evolution_prepare. The mask is what hid the abort in the first place — a broken migration must stop the boot.

Root cause

The account/user removal refactor (9944be0) only touched db/schema.rb; the downstream migrations that reference :users were never scrubbed. The version: 9025_08_19_224901 bump in that same commit papers over the problem via assume_migrated_upto_version — it only works on the db:schema:load path. Any db:migrate on an empty DB still walks the migrations in chronological order and hits the FK abort.

Test plan

  • db:migrate against a clean Postgres completes: 51/51 migrations applied, 0 pending.
  • \d attachments on the resulting DB shows attachable_type / attachable_id (with index_attachments_on_attachable_type_and_attachable_id) and no message_id.
  • schema_migrations contains 20251119155458 (the previously-blocked polymorphic migration).
  • Deploy against an existing installation that already patched the columns manually: confirm MakeAttachmentPolymorphic idempotency (may need a follow-up guard).
  • Smoke the Sidekiq webhook receiving media and the contact deletion flow end-to-end once the image is rebuilt.

Seven migrations still referenced a users table that no longer exists in
community (identity now lives in evo-auth-service). db:migrate aborted on
the first of them (CreateFacebookCommentModerations), which in turn
blocked MakeAttachmentPolymorphic and left attachments stuck with the
legacy message_id column. Sidekiq/Puma then crashed with
PG::UndefinedColumn: attachments.attachable_id does not exist whenever
media or contact deletion touched the table.

Replace each FK to :users with a plain uuid column (keeping the same
column names so models keep working) plus manual indexes where the
auto-generated ones disappeared.

Also stop docker-entrypoint.sh from masking boot errors with
2>/dev/null || true — that mask is what hid this abort in the first
place. db:evolution_prepare already covers create + schema:load + migrate
in one call, so collapse the three-command dance into a single
unmasked invocation.
Copy link
Copy Markdown

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @gomessguii, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant