No automatic application of DB migrations on updating to 0.15.1

[shapirus]

Please verify that this bug has NOT been raised before.

• I checked and didn't find a similar issue

Describe the bug*

After updating from 0.14.4 to 0.15.1, opening a part page results in an error 500; the django error page says the following:

OperationalError at /part/19/

(1054, "Unknown column 'part_supplierpart.active' in 'field list'")

Request Method: 	GET
Request URL: 	http://localhost:9100/part/19/
Django Version: 	4.2.12
Exception Type: 	OperationalError
Exception Value: 	

(1054, "Unknown column 'part_supplierpart.active' in 'field list'")

Exception Location: 	/root/.local/lib/python3.11/site-packages/MySQLdb/connections.py, line 261, in query
Raised during: 	part.views.PartDetail

I believe a traceback isn't necessary, but please let me know if it is.

It looks like a missed db migration, but I have verified that INVENTREE_AUTO_UPDATE is set to "true" (string value) in my deployment (specifically, via an env file included via the env_file docker_compose parameter).

update: yes they did not run, see later comments.

Steps to Reproduce

1. Update from 0.14.4 to 0.15.1
2. Open a part

I can't reproduce it on the demo site, so it's either fixed in 0.16.0-dev, or the necessary migration failed to run on my instance even though the auto update flag is set.

Expected behaviour

no exceptions.

Deployment Method

• Docker
• Package
• Bare metal
• Other - added info in Steps to Reproduce

Version Information

# Version Information:
InvenTree-Version: 0.15.1
Django Version: 4.2.12
Commit Hash: be3b22c
Commit Date: 2024-05-15

Database: mysql
Debug-Mode: True
Deployed using Docker: True
Platform: Linux-4.19.0-16-cloud-amd64-x86_64-with
Installer: DOC

Active plugins: [{'name': 'InvenTreeBarcode', 'slug': 'inventreebarcode', 'version': '2.0.0'}, {'name': 'InvenTreeCoreNotificationsPlugin', 'slug': 'inventreecorenotificationsplugin', 'version': '1.0.0'}, {'name': 'InvenTreeCurrencyExchange', 'slug': 'inventreecurrencyexchange', 'version': '1.0.0'}, {'name': 'InvenTreeLabel', 'slug': 'inventreelabel', 'version': '1.0.0'}, {'name': 'InvenTreeLabelMachine', 'slug': 'inventreelabelmachine', 'version': '1.0.0'}, {'name': 'InvenTreeLabelSheet', 'slug': 'inventreelabelsheet', 'version': '1.0.0'}, {'name': 'DigiKeyPlugin', 'slug': 'digikeyplugin', 'version': '1.0.0'}, {'name': 'LCSCPlugin', 'slug': 'lcscplugin', 'version': '1.0.0'}, {'name': 'MouserPlugin', 'slug': 'mouserplugin', 'version': '1.0.0'}, {'name': 'TMEPlugin', 'slug': 'tmeplugin', 'version': '1.0.0'}]

Please verify if you can reproduce this bug on the demo site.

• I can reproduce this bug on the demo site.

Relevant log output

No response

[shapirus]

Well, guess what.

I ran docker-compose -f docker-compose.yml run --rm inventree-server invoke update manually:

There are 8 pending migrations
- InvenTree.0002_auto_20240514_2346
- build.0049_alter_builditem_build_line
- build.0050_auto_20240508_0138
- company.0069_company_active
- otp_static.0003_add_timestamps
- otp_totp.0003_add_timestamps
- stock.0109_add_additional_test_fields
- stock.0110_alter_stockitemtestresult_finished_datetime_and_more
Starting migration process...
Operations to perform:
  Apply all migrations: InvenTree, account, admin, auth, build, common, company, contenttypes, django_q, error_report, exchange, flags, label, machine, order, otp_static, otp_totp, part, plugin, report, socialaccount, stock, taggit, user_sessions, users
Running migrations:
  Applying InvenTree.0002_auto_20240514_2346... OK
  Applying build.0049_alter_builditem_build_line... OK
  Applying build.0050_auto_20240508_0138... OK
  Applying company.0069_company_active... OK
  Applying otp_static.0003_add_timestamps... OK
  Applying otp_totp.0003_add_timestamps... OK
  Applying stock.0109_add_additional_test_fields... OK
  Applying stock.0110_alter_stockitemtestresult_finished_datetime_and_more... OK
There are 0 pending migrations
Completed 8 migrations

...and of course it fixed the issue.

Now, was it a one-off glitch in my specific instance, or there is something preventing migrations from running automatically on updating from 0.14(.4) to 0.15(.1), despite the respective env variable is set? Has anyone else encountered this? If not, then I guess the issue can be considered resolved/unreproducible.

[SchrodingersGat]

@shapirus an interesting issue. Is the background worker container up and running? When booting the server, if INVENTREE_AUTO_UPDATE is enabled, a task is pushed off to the background worker thread to check for any pending migrations,

[shapirus]

Is the background worker container up and running?

It is. I think I did watch its output during some time after updating the docker image tag (or rather tags: for server and worker), and now I think I didn't see any migrations related output.

Actually I still have my old 0.14.4 db backed up, so I may try to reproduce it. Will check when I have time.

[SchrodingersGat]

If you can run some further tests that would be very useful!

[matmair]

@shapirus is this still reproducible in the latest release 0.15.3?

[shapirus]

Unfortunately I've had no chance to test it yet.

@matmair were there any database schema changes between 0.15.1 and 0.15.3? If there were, then testing it becomes trivial: I will simply have to update my deployment from 0.15.1 to 0.15.3 and see if the migrations will run, and in that case I can do it tomorrow.
This won't test the 0.14.x->0.15.3 update path, though, but if the code responsible for this is the same, then it'll still be good enough.

[shapirus]

An important note: I have just noticed that the old 0.14.4 version of the inventree image was still specified for the worker in the docker-compose file, and I only updated the server. Facepalm!

I am not sure whether that was the root cause of the issue, but it may very well be so!

Either way, I am now going to upgrade both the server (from 0.15.1) and worker (from 0.14.4) images to 0.15.3 and see what happens.

[shapirus]

So yes:

inventree-worker_1  | There are 2 pending migrations
inventree-worker_1  | - InvenTree.0002_auto_20240527_1009
inventree-worker_1  | - users.0011_auto_20240523_1640
inventree-worker_1  | Starting migration process...
inventree-worker_1  | Operations to perform:
inventree-worker_1  |   Apply all migrations: InvenTree, account, admin, auth, build, common, company, contenttypes, django_q, error_report, exchange, flags, label, machine, order, otp_static, otp_totp, part, plugin, report, socialaccount, stock, taggit, user_sessions, users
inventree-worker_1  | Running migrations:
inventree-worker_1  |   Applying InvenTree.0002_auto_20240527_1009... OK
inventree-worker_1  |   Applying users.0011_auto_20240523_1640...Cleared all user sessions to deal with GHSA-2crp-q9pc-457j
inventree-worker_1  |  OK

Indeed, it's the worker that is responsible for running the migrations. No surprise that they did not run in my case.

Such a silly mistake to update one image but not the other. I believe the issue can be considered resolved now.

[SchrodingersGat]

Glad you got it worked out