Migration failed silently and stops ghost from starting

I recently upgraded from v3.12.1 to v3.42.4 in preparation for upgrading to v4.

I exported my data, upgraded to the latest ghost-cli version, and the went through the progress by running ghost update v3.

It went through the steps with no errors and tried to restart my instance using systemctl. I checked the url after this and it failed to load.

Upon further inspection of the logs, it gives the following error, which makes me think the migration didn’t happen successfully.

Mar 24 17:45:19 code-by-vernacchia node[31039]: #033[90m----------------------------------------#033[39m
Mar 24 17:45:19 code-by-vernacchia node[31039]: #033[90mRollbackError: show columns from `email_recipients` - ER_NO_SUCH_TABLE: Table 'ghost_code_db.email_recipients' doesn't exist
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at RollbackError.KnexMigrateError (/var/www/ghost/versions/3.42.4/node_modules/knex-migrator/lib/errors.js:7:26)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at new RollbackError (/var/www/ghost/versions/3.42.4/node_modules/knex-migrator/lib/errors.js:31:26)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at /var/www/ghost/versions/3.42.4/node_modules/knex-migrator/lib/index.js:440:23
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at tryCatcher (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/util.js:16:23)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at Promise._settlePromiseFromHandler (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/promise.js:547:31)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at Promise._settlePromise (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/promise.js:604:18)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at Promise._settlePromise0 (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/promise.js:649:10)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at Promise._settlePromises (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/promise.js:725:18)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at _drainQueueStep (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/async.js:93:12)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at _drainQueue (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/async.js:86:9)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at Async._drainQueues (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/async.js:102:5)
Mar 24 17:45:19 code-by-vernacchia node[31039]:     at Immediate.Async.drainQueues [as _onImmediate] (/var/www/ghost/versions/3.42.4/node_modules/bluebird/js/release/async.js:1

How would I go about fixing this so I can get my block backup and running?

Technical details:

• Ghost-CLI version: 1.16.3
• Ghost version: 3.42.4
• Node Version: v10.24.0
• Database: MySQL

[vernak2539]

Hey @ErisDS, thanks for the response and for updating the template (when I submitted this a year ago I didn’t know the forum existed)

A quick questionif you don’t mind. You said that github is for reproducible bugs. I feel like this is a reproducible bug due to the fact that others are running into it. I know it’s not a bug that details code execution paths in certain conditions, but a bug nonetheless. I would think that migration problems aren’t environment problems, but rather bugs, especially if you’re migrating between minor versions with tooling provided. This isn’t how Ghost views it?

[ErisDS]

90% of the time migration errors are caused by configuration problems on the host system, usually one of the problems documented here. Multiple people might encounter the same misconfiguration, but that doesn’t constitute a bug in the migrations.

If I can spin up a DO 1-click droplet and always reproduce the problem using the recommended stack, that’s a bug in the migrations.

Everything else is a question of whether or not Ghost CLI should detect or do something with the environment problem to make it easier to find, but ultimately that requires code to be written by someone & again 90% of the time the person encountering the config issue solves their config issue and moves on rather than contributing any improvements.

As a small team, we focus on things that are reproducible on the recommended stack, but that doesn’t preclude anyone from coming along and contributing improvements if they want to.