Bootstrap Container si blocca su su discourse -c 'bundle exec rake db:migrate'

Bug
1

We are currently running this recent release:

It’s still running in our production container (no issues).

I’m trying to bootstrap based on this release:

I’ve tried a number of times today, and each time it hangs here:

Screen Shot 2021-02-11 at 5.32.24 PM

Checked the logs in the data and the standby app container (we are bootstrapping) and there are no errors, no issues.

Each time I bootstrap, it hangs on this line:

I, [2021-02-11T10:37:25.133098 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'

Any clues where to look to help debug this?

I’ve looked in all the logs I can think of (in all containers) and cannot find problems.

Thanks.

Additional Info:

Each time it hangs and I control C out of the bootstrap process, it seems to leave a postmaster process, which I can subsequently kill.

Here is an example:

Screen Shot 2021-02-11 at 5.49.42 PM
Screen Shot 2021-02-11 at 5.49.42 PM847×188 65.8 KB

Update:

Bootstrap rebuilds fine if I comment out the “db:migrate” line in the web template.

There is some strange issue with “rails db:migrate” hanging with zero errors I have never experienced before.

I wonder if there is an error (or some underlying issue) in this recent migration?

See also:

2

Hi @neounix, we’re aware of an issue with the migration you linked and we’re working on a fix right now

2 Mi Piace
3

Hi @david

Thanks for the reply!

I was looking at the migration just now, and my first thought, as “not a Discourse DB migration expert”, was this might be the issue ?

 add_index :dismissed_topic_users, %i(user_id topic_id), unique: true

Anyway, I’m not qualified to go much deeper into Discourse migration issues, so I’ll stand down and stand by.

Thanks again!

4

Can we safely abort the Migration without any data loss and go back a few commits?

It worked.

1 Mi Piace
5

Hey @neounix,

sorry for including that heavy and broken migration into the codebase. Those changes were reverted so new deploy should be fine:

4 Mi Piace
6

Hi @kris.kotlarek

Thank you for the update:

I tend to agree that that this “heavy migration” more-than-likely requires additional review and stringent development testing on a test configuration with a large DB before merged into core. Lucky for our site, I always bootstrap in parallel to production so we did not suffer any downtime during the migration failure(s), so no worries on our end. Thanks for reverting so quickly.

FYI only (just being technically precise, sorry about that… ), I checked the DB after rebuilding just now and the “revert” process did not drop the table from DB, no big deal, just FYI only:

discourse=> \d dismissed_topic_users

                                        Table "public.dismissed_topic_users"
   Column   |            Type             | Collation | Nullable |                      Default                      
------------+-----------------------------+-----------+----------+---------------------------------------------------
 id         | bigint                      |           | not null | nextval('dismissed_topic_users_id_seq'::regclass)
 user_id    | integer                     |           |          | 
 topic_id   | integer                     |           |          | 
 created_at | timestamp without time zone |           |          | 
Indexes:
    "dismissed_topic_users_pkey" PRIMARY KEY, btree (id)
    "index_dismissed_topic_users_on_user_id_and_topic_id" UNIQUE, btree (user_id, topic_id)

Thank you again for your hard work on this and for quickly reverting the migration.

2 Mi Piace
7

This migration is working smoothly now, based on the latest commit:

4 Mi Piace
8

This topic was automatically closed after 6 days. New replies are no longer allowed.