Error on search_api_update_8110

Thanks for reporting this problem!

Is it possible for you to look at the database structure? Is there a UNIQUE index on the search_api_task.data column?
It seems pretty absurd that dropping an index would lead to this exception, when it seems to have been created just fine.

In any case, I hope this is not a larger problem, but confined to specific setups.

OK, thanks. Very strange. Can you drop that task__unique index manually?
What’s your database software and version?

Looks like this might be caused by this MySQL bug. If it is, it should be fixed by the 8.0.22 release. (Though the ticket doesn’t say whether you’ll then be able to drop the index, or whether it only prevents new indexes from being created.)

Not sure what the best solution for this module would be. The index doesn’t really do any harm, or only in very few cases, so just catching the error and reporting a warning might be OK? Otherwise, not really sure how to resolve this, to be honest. (As this is all done by the entity updater service, we can’t even change the SQL used for this.)

It seems that this might be a known bug for Percona before 8.0.22. Which is unfortunate, of course – probably you cannot just update Percona to that?
What’s the exact syntax you used for removing the index manually? DROP INDEX … ON search_api_task?
Then maybe we can use that as a fallback for this special case? Attached is a first attempt at this, would be great if you could give it a try. Looks pretty shaky, though, so I hope this is not a wide-spread problem.

Also, I guess it makes sense to not even add that index in the first place in case someone updates from an earlier version of the module? It’s a bit late now, I guess, but still this patch should also keep the index from being created in the first place in that situation.
Not 100% sure, though, probably this should have some additional eyes on it to make sure we don’t introduce yet another bug in relation to this damn index.

#3248262: Call to a member function setHandlerClass() on null (update_8107 in 1.21) discusses yet another problem with the 8107 update, which could also affect 8110. I have proposed similar changes there, will need to take care to re-roll accordingly when commiting either one.

I have this exact problem, also on Acquia CLoud, after updating to 1.23 of this module -- weirdly, it is ONLY effecting 3 of my 5 multisites... which is a real head scratcher.

Will take a look at this patch, and see also what DB software we're on for those multistes that are throwing this error.

Same happening for me in Acquia. Let me try this patch.

I ran into this problem on Acquia Cloud, and neither this patch nor ones on https://www.drupal.org/node/3248262 did the trick.

However, I DID manage to fix things by disabling search_api, running database updates, and then re-enabling it and all its dependent modules.

drush pmu search_api
drush updb -y
drush en search_api search_api_solr acquia_search etc....

Given the error looks like this bug in MySQL tables the only other fix would be a full database restore, which would rebuild the tables, and allow the database updates to work. This is why it was working for me in lower Acquia environments, but failed on production.

Same happening for me in AWS hosted site. Let me try this patch.

Re-roll necessitated by #3248262: Call to a member function setHandlerClass() on null (update_8107 in 1.21).