Discourse Upgrade from 3.2.0 to 3.3.0 Postgress issue

Product Support Self-hosting

AI-generated summary

A user reported an issue during a Discourse upgrade from 3.2.0 to 3.3.0, where database migration failed due to dependency on the user_id column in the invites table, caused by triggers like invites_user_id_readonly. The user resolved it by manually dropping three triggers. They created a PR to address the issue Ali_UĞUR, but it was closed by another user gerhard who couldn’t reproduce the problem and noted that the migration code should automatically handle trigger dependencies via CASCADE. The discussion questions whether this is a Discourse bug and if a fix is planned.

1

Hi! I tried to upgrade my Discourse v3.2.0 instance to v3.3.0. When it was running the database migrations it failed.

Execute db:migrate
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)
ERROR:  cannot drop column user_id of table invites because other objects depend on it
DETAIL:  trigger invites_user_id_readonly on table invites depends on column user_id of table invites
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

I fixed this by dropping 3 triggers in the database:

DROP TRIGGER invites_user_id_readonly ON invites;

DROP TRIGGER invites_redeemed_at_readonly ON invites;

DROP TRIGGER user_api_keys_scopes_readonly ON user_api_keys;

My actual question is, can you confirm this is an error on Discourse side? Do you have plans to fix it in the future?

I have PostgreSQL 14.10 running.

2

Created a PR for fixing this issue.
https://github.com/discourse/discourse/pull/28820

3

I’m closing that PR because I can’t reproduce the issue and nobody else reported a similar issue.

Migration::ColumnDropper.execute_drop drops the read_only function for each column with CASCADE. That also drops the trigger.

It sounds like you had a trigger that didn’t reference the read_only function. I’m not sure how you managed to do this. Are you using a standard install?