- Issue created by @basby
- Status changed to Postponed: needs info
12 months ago 2:56pm 8 January 2024 - 🇨🇦Canada _randy
Generally you'll only get that message when there is data in the column. However, you've noted that there isn't any data.
Before you do anything, always start by taking a full backup.
Then, on a non-production development system, try setting the maestro_queue token column to blanks and re-running the update.
Warning, this will update each row in the maestro_queue table:UPDATE maestro_queue SET token=''
Then try running the update again. But again, only do this on a non production development system.
- 🇳🇱Netherlands basby
Thanks _randy, for your help!
After reading your comment, I double checked the token column. It appears that they are not all empty.
Any idea on what I can do in that case?
- 🇨🇦Canada _randy
The task console detects if there is a queue token or not.
If no queue token exists for the task, it reverts back to the original mechanism for launching/executing tasks. Otherwise it will use a token.I'm not sure if you've set the Maestro URL Tokens ( https://www.drupal.org/docs/contributed-modules/maestro/maestro-api#s-ma... → )
If you've not set the token, Maestro will fall back on the older queueIDs-in-URLs for things like the task console and task URL generation.
There are a couple places where established tasks will save/cache their URLs in the database. This is why I would do what I suggest later on in this note.Technically, you can remove the token in the setting listed above, and the site should generate URLs with the queueID instead. This way you can work on clearing the tokens in the maestro_queue table and then running the updates.
You can also do something a bit more crafty, like
- Copying the maestro_queue table to a new temporary table.
- set the maestro_queue table token column to blank/null
- perform drupal update
- use sql to copy the tokens from the copied temporary queue table token column to the maestro_queue token column
- 🇳🇱Netherlands basby
I have done the more crafty work you suggested. The token field is now updated and the error has disappeared. Thank you, maestro _randy!
If anyone else comes across the same issue, this is what I did in detail.
- Made a copy of the code and database.
- (in phpMyAdmin) Copied the maestro_queue table to a new temporary table:
CREATE TABLE maestro_queue_copy AS SELECT * FROM maestro_queue
- (in phpMyAdmin) Set the maestro_queue table token column to blank/null:
UPDATE maestro_queue<br /> SET token=NULL
- (on the command line) Updated the entity:
drush entity-updates
- (in phpMyAdmin) Copied the tokens from the copied temporary queue table token column to the maestro_queue token column:
UPDATE maestro_queue AS m1<br /> INNER JOIN maestro_queue_copy AS m2 ON m1.id = m2.id<br /> SET m1.token = m2.token
- (in phpMyAdmin) Deleted the temporary queue table
DROP TABLE maestro_queue_copy
- 🇺🇸United States jsweetack
I have the same issue, however I'm not using 'drush entity-updates' because it doesn't exist on my system. I see you can download and enable the devel_entity_updates module for TEST environments but not production. Many warnings about how you should NOT use it in a production environment, and how "maintainers of the module should fix the entity issue." So, unsure of what to do next, and whether this is breaking anything currently.
- 🇳🇱Netherlands basby
jsweetack, you can install drush following the steps in https://drupalize.me/tutorial/install-drush-using-composer.
Summary:
* Go to the root directory of your project and install drush using
composer require --dev drush/drush
* Check if drush is installed correctly:
./vendor/bin/drush --version
Now you can use 'drush entity-updates'.
- 🇮🇳India keshavv India
Please look into this comment.
https://www.drupal.org/project/address/issues/3412241#comment-15408612 🐛 Mismatched field definitions after address upgrade Needs review - 🇺🇸United States jsweetack
@basby - I have drush, you need to install the devel_entity_updates module for that to work on current versions of drush, and as I stated, it appears that's not the right way to go for production servers, hence why I'm not installing that module.
@keshavv - thank you, I will look into that.