Right now, unless you have index_immediately enabled for your index, indexItems() doesn't actually index anything. It just prepares it and registers a shutdown function to submit the query.
That as a few issues IMHO
if indexItems() does not return an error, the tracker considers those items to be successfully indexed. If the commit then results in an exception, that will not be updated in the tracker.
In some cases, this can result in weird issues. I have a behat test where I have a step definition to run cron, that doesn't actually index because the process continues to run.
I can imagine that it would also be problematic for batch-indexing, because it won't properly integrate with the batch execution time stuff.
The current coupling to index_immediately is weird. My initial reaction was that it should be the other way round, that index immediately should be delayed to the end of the request to not let the user wait, but there might be cases where you want your content to be in the index immediately... ?
Suggestion:
Keep the feature, but make it configurable globally or per server, completely separated from index_immediately.
Right now, unless you have index_immediately enabled for your index, indexItems() doesn't actually index anything. It just prepares it and registers a shutdown function to submit the query.
That as a few issues IMHO
Suggestion: Keep the feature, but make it configurable globally or per server, completely separated from index_immediately.