Fix current test failures

Yes, thanks this fix works.

But, personally, I feel using the whole data column as a key may be a design issue. Thinking loud here, it would be maybe better to apply an md5 hash on data itself, index that as an extra field/column and use that as unique to avoid double tracking. The hypothetical scenarios or something not being tracked because of a partial match do worry me specially because they would be quite hard to debug. I have always seen trackers like queues, that are by design totally unaware of any other entry. That makes them atomic and failsafe. Repeating an Solr document indexing less process intensive that querying the DB for its existence. Again, my 25cents and I came late to the discussion.

Sorry for my late response. Too many moving targets lately. Clever fix by identifying the driver! Thanks so much

Hello,

If this may help anyone. I encountered an issue when deploying on prod for my personal website. And this is what I had done.

Add in the my.cnf:

[mysqld]
innodb_file_format    = Barracuda
innodb_file_per_table = ON
innodb_large_prefix   = ON
innodb_default_row_format = 'DYNAMIC'

Restart MariaDB and then convert existing tables with:

mariadb --batch --skip-column-names --execute 'SELECT CONCAT("ALTER TABLE `", TABLE_SCHEMA,"`.`", TABLE_NAME, "` ROW_FORMAT=DYNAMIC;") AS MySQLCMD FROM information_schema.TABLES WHERE ENGINE="innodb" AND ROW_FORMAT != "DYNAMIC" AND ROW_FORMAT !="COMPRESSED" AND TABLE_SCHEMA="MYDRUPALDATABASE"' | mysql

Then the hook_update_N was ok.

FYI I have opened #3248297: Default tests failing over at the Facets module which seems to be (somehow) related to this change. Tests that were passing as of 6 Oct. 2021 now appear to be failing with a similar key length error despite (because of?) this patch. I'm confused here about how this patch fixed an issue here but maybe causes the same issue in Facets. You can see in the failed test example on that issue the new UNIQUE KEY `task__unique` (`type`, `server_id`, `index_id`, `data`(255)) part of the query.

Anyone have thoughts on how these are related? I'm stumped at the moment.

I seem to have the same issue as Grimreaper.

The update hook 8107 fails with this message:

General error: 1709 Index column size too large. The maximum column size is 767 bytes: ALTER TABLE "search_api_task" ADD UNIQUE KEY `task__unique` (`type`, `server_id`, `index_id`, `data`(255));

I assume it is due to the collation set to utf8_mb4, which leads to a necessary column size of 4 * 255 = 1020 bytes, exceeding the 767 bytes in our MariaDB 10.5.12 environment.

It seems that the Facets tests failures and the issues noted by @Grimreaper and @mrshowerman are all the same thing — this commit made the module essentially incompatible with MySQL 5.6 in certain (default? and testbot) configurations.

With the deprecation of D8 maybe this is acceptable? Drupal 9+ requires MySQL 5.7+ where this doesn’t seem to be an issue.

Thanks @wells for pointing me in the right direction. Turns out that back when I installed Search API, I was still using MariaDB 10.1.48, so the search_api_task table got created with the COMPACT row format. Even after upgrading to 10.5.12 later on, the row format didn't change, leading to the above error.
I fixed it by running the following:

MariaDB [dbname]> alter table search_api_task row_format=dynamic;

Now the update script was able to create the index.