Steps to reproduce the issue

Trying to index a new, or reindex J4 smart search content that also includes the YOOTheme ZOO component throws a "undefined" modal error. Since I believe this is possibly a YOOTheme specific issue, I submitted this issue to their dev team as well but wanted to also make provide this to the J4 team as there might be some crossover issue that needs to be addressed.

Expected result

Reindexing the smart search should complete without error. If I enable the "search - zoo" or "smart search - zoo" plugins, the smart search index will fail.

Actual result

Indexing a new, or updating the smart search index creates an error, both from the J4 administrative interface as well as running the CLI script from SSH

System information (as much as possible)

I'm running an an Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz', 3800MHz, 6 Core, 32GB Ram
Joomla: v4.3.4
Template: Helix Ultimate v2.0.14
Zoo Component: v4.1.38
PHP: v8.1
Database Version: v10.5.22-MariaDB

Additional comments

I logged into the admin side of my site, cleared out all of the indexed content so it was completely empty and ran the indexing CLI script from SSH. Sometimes it completed successfully (though it could often take anywhere from 20-60 minutes to complete), other times it got part way through and then crashed with a "broken pipe" error. Below are a few examples of the SSH results - again, keep in mind that after each attempt I went back into the admin side of the site and cleared out the index so this was indexing everything fresh.

In this example you'll notice that batch 3 took ~53 minutes and then crapped out with a "client_loop: send disconnect: Broken pipe" error. It never got to batch 4.

`/opt/plesk/php/8.1/bin/php /var/www/vhosts/domain.org/dev.domain.org/cli/joomla.php finder:index --verbose
Finder Indexer

Starting Indexer
Setting up Smart Search plugins
Setup 156 items in 0.034 seconds.

• Processed batch 1 in 4.86 seconds.
• Pausing processing for 1 seconds …
• Continuing processing of batch …
• Processed batch 2 in 12.604 seconds.
• Pausing processing for 3 seconds …
• Continuing processing of batch …
• Processed batch 3 in 3201.065 seconds.
• Pausing processing for 640 seconds …
  client_loop: send disconnect: Broken pipe`

This one made it to batch 4, but took over 20 minutes on batch 3 and still give me that "client_loop: send disconnect: Broken pipe" error.

`/opt/plesk/php/8.1/bin/php /var/www/vhosts/domain.org/dev.domain.org/cli/joomla.php finder:index --verbose
Finder Indexer

Starting Indexer
Setting up Smart Search plugins
Setup 156 items in 0.037 seconds.

• Processed batch 1 in 4.887 seconds.
• Pausing processing for 1 seconds …
• Continuing processing of batch …
• Processed batch 2 in 11.817 seconds.
• Pausing processing for 2 seconds …
• Continuing processing of batch …
• Processed batch 3 in 1427.885 seconds.
• Pausing processing for 286 seconds …
• Continuing processing of batch …
• Processed batch 4 in 1.632 seconds.

Total Processing Time: 1735.26 seconds.
Peak memory usage: 41,943,040 bytes
client_loop: send disconnect: Broken pipe`

It wouldn't be fair to only show the failures, so here's a script example that completes a fresh index successfully - though again after about 23 minutes. I don't know what content is in what batch, but I know that I always have only 4 batches and from trial and error I believe the ZOO content is in batch 3 if only because it's the one that takes the longest.

`/opt/plesk/php/8.1/bin/php /var/www/vhosts/domain.org/dev.domain.org/cli/joomla.php finder:index --verbose
Finder Indexer

Starting Indexer
Setting up Smart Search plugins
Setup 156 items in 0.04 seconds.

• Processed batch 1 in 5.099 seconds.
• Pausing processing for 1 seconds …
• Continuing processing of batch …
• Processed batch 2 in 13.227 seconds.
• Pausing processing for 3 seconds …
• Continuing processing of batch …
• Processed batch 3 in 1427.843 seconds.
• Pausing processing for 286 seconds …
• Continuing processing of batch …
• Processed batch 4 in 1.576 seconds.

Total Processing Time: 1737.786 seconds.
Peak memory usage: 41,943,040 bytes`

As a delta reference point, if I have already successfully indexed all of the content and I then try to run the CLI script from SSH, it rips through the steps very quickly as shown in this example. Again, this is running the CLI script on content that's already been indexed. Unfortunately trying to run the index updater from the J4 admin side still gives me the 'undefined' error.

`/opt/plesk/php/8.1/bin/php /var/www/vhosts/domain.org/dev.domain.org/cli/joomla.php finder:index --verbose
Finder Indexer

Starting Indexer
Setting up Smart Search plugins
Setup 156 items in 0.05 seconds.

• Processed batch 1 in 0.183 seconds.
• Skipping pause, as previous batch had a very low processing time (0.183s < 1s)
• Processed batch 2 in 0.23 seconds.
• Skipping pause, as previous batch had a very low processing time (0.23s < 1s)
• Processed batch 3 in 0.197 seconds.
• Skipping pause, as previous batch had a very low processing time (0.197s < 1s)
• Processed batch 4 in 0.024 seconds.
• Skipping pause, as previous batch had a very low processing time (0.024s < 1s)

Total Processing Time: 0.685 seconds.
Peak memory usage: 29,360,128 bytes`

So in a more concise manner:

• Fresh indexing from the J4 admin side, will start (green bar starts to move) but then errors with that "undefined" error.
• Fresh indexing from SSH, will complete (most of the time) though it can often take anywhere from 30-60 minutes to index only 156 items.
• Update-indexing from the J4 admin side will almost immediately give that same "undefined" error.
• Update-Indexing from SSH will complete very quickly and so far has never produced any errors with this process.
• All of these steps have been repeated multiple times with both empty indexes as well as reindexing currently existing indexes.
• Most importantly, none of these issues happen if I disable the "Search - ZOO" and "Smart Search - ZOO" plugins from the J4 admin side.

Again, I believe this is most likely an issue specifically related to YOOTheme's component but I also wanted to provide it to fresh eyes on the J4 team which might have some additional thoughts or insight as to why this would be happening and if there's anything on their side of the equation that could be addressed.