Call to a member function preExecute() on null in SearchApiTimeCache::generateResultsKey()

Seems like this error occurs at multiple places hence created a META issue for it.

Getting the same error on line 293, added null safe operator.

Hi,

Applied the patch #4 to 1.28.0 but still got this message:

PHP message: Error: Call to a member function getResults() on null in /var/www/html/learn_test/web/modules/contrib/search_api/src/Plugin/views/query/SearchApiQuery.php on line 867 #0

Added the patch for the issue mentioned in #6, here is the updated patch(Call_on_Null-3321499-7.patch) and interdiff_4-7.txt

Situations, when indexes are disabled, won't lead you to a fatal error using views with search_api, thanks to this patch.

#7 works for me.

Thanks a lot for your comment, mialdi98, this is the first clue to the cause of this issue. With this, I was also easily able to reproduce at least one of the errors.
Can others confirm that they also have a disabled search index on their site?

Otherwise, it would be very important to know why getSearchApiQuery() returns NULL, so that we don’t just apply a band aid that fixes the symptoms but ignore the underlying problem.

Regarding the patches: We don’t yet depend on PHP 8, so please use the long syntax for null safety. Patch attached, please test/review!

In my case, I did have a disabled search index when running facets_update_8010. The patch in #9 fixed the issue.

We had the same issue and under same scenarios.
We had a disabled search index and we ended up on the same error. Also other update hooks from Facet module facets_update_8012 was failing for the same error.

I can also confirm after applying the patch #9, the issue got fixed. Thanks for the patch.

I think we can move to RTBC!

Good to hear, thanks for testing and reporting back!
Merged.
Thanks again, everyone!

I think the previous patch/commit is still incomplete as I landed on the error while accessing view:
TypeError: Drupal\search_api\Utility\QueryHelper::addResults(): Argument #1 ($results) must be of type Drupal\search_api\Query\ResultSetInterface, null given, called in /var/www/html/docroot/modules/contrib/search_api/src/Plugin/views/cache/SearchApiCachePluginTrait.php on line 186 in Drupal\search_api\Utility\QueryHelper->addResults() (line 86 of modules/contrib/search_api/src/Utility/QueryHelper.php).

Its kind of expected since the query is NULL, so the result set in https://git.drupalcode.org/project/search_api/-/blob/8.x-1.x/src/Plugin/... also becoming null.

Since previous patch is already committed, adding a second patch to fix it (excluding the changes in #9). Please review!

For people who are facing such, you need both this patch and the patch in #9 to make it work.

Thanks for reporting this, that indeed seems to be a similar probolem.
However, the solution is probably to avoid caching a NULL result in the first place, not to add a check when retrieving it.
Patch attached, please test/review!

Re-written patch #15 to be compatible with the latest version.

@namisha jadhav: Thanks! I added that to the MR, let’s see what the test bot says.

I use Drupal 11.0.12, search API 8.x-1.38, and search API Solr 4.3.8. In view, I'm using the cache as a Search API tag-based.

TypeError: Drupal\search_api\Utility\QueryHelper::addResults(): Argument #1 ($results) must be of type Drupal\search_api\Query\ResultSetInterface, null given, called in /var/web/vd16430/app/releases/303/web/modules/contrib/search_api/src/Plugin/views/cache/SearchApiCachePluginTrait.php on line 201 in Drupal\search_api\Utility\QueryHelper->addResults() (line 86 of /var/web/vd16430/app/releases/303/web/modules/contrib/search_api/src/Utility/QueryHelper.php).

I used the patch from MR 101, then cleared the cache, re-indexed all the items but I still see that error.

While on Drupal 10.4, search API 1.35 and search API solr 4.3.4 and everything works fine with the views cache set to Search API tag-based.

Huh, that’s very strange, no idea how this could even happen. Do you have any custom or third party caching code for Views results that might interfere? Do you also see a warning for an “undefined array key” before the TypeError occurs?
Would be very interesting to catch the moment where the faulty data is cached via a conditional breakpoint in \Drupal\Core\Cache\DatabaseBackend::set() (or other used cache backend).

But I guess for the sake of getting this long-running issue finally fixed we can also just add an explicit check for whether that key is empty and avoid using the cached data otherwise. Added to the MR, please test/review!

I don't see any warning before that TypeError occur. I do see array offset warnings after that if ($cache = $this->getCacheBackend()->get($this->generateResultsKey())) {

But that is because of the results are null.

I also noticed this warning which has search api in backtrace.

Warning: unserialize(): Error at offset 35560 of 168513 bytes in Drupal\Component\Serialization\PhpSerialize::decode() (line 21 of /var/www/core/lib/Drupal/Component/Serialization/PhpSerialize.php) #0 /var/www/core/includes/bootstrap.inc(108): _drupal_error_handler_real(2, 'unserialize(): ...', '/var/web/vd1642...', 21)
#1 [internal function]: _drupal_error_handler(2, 'unserialize(): ...', '/var/www...', 21)
#2 /var/www/core/lib/Drupal/Component/Serialization/PhpSerialize.php(21): unserialize('a:4:{s:6:"resul...')
#3 /var/www/modules/contrib/redis/src/Cache/CacheBase.php(390): Drupal\Component\Serialization\PhpSerialize::decode('a:4:{s:6:"resul...')
#4 /var/www/modules/contrib/redis/src/Cache/PhpRedis.php(68): Drupal\redis\Cache\CacheBase->expandEntry(Array, false)
#5 /var/www/modules/contrib/redis/src/Cache/CacheBase.php(159): Drupal\redis\Cache\PhpRedis->getMultiple(Array, false)
#6 /var/www/modules/contrib/search_api/src/Plugin/views/cache/SearchApiCachePluginTrait.php(192): Drupal\redis\Cache\CacheBase->get('search:search_o...')
#7 /var/www/core/modules/views/src/ViewExecutable.php(1479): Drupal\search_api\Plugin\views\cache\SearchApiTagCache->cacheGet('results')
#8 /var/www/core/modules/views/src/ViewExecutable.php(1514): Drupal\views\ViewExecutable->execute(NULL)
#9 /var/www/core/modules/views/src/Plugin/views/display/Block.php(133): Drupal\views\ViewExecutable->render()
#10 /var/www/core/modules/views/src/ViewExecutable.php(1690): Drupal\views\Plugin\views\display\Block->execute()
#11 /var/www/core/modules/views/src/Element/View.php(81): Drupal\views\ViewExecutable->executeDisplay('search_overview', Array)

I don't know whether it is related or not.

But the latest commit indeed fixes the error.

Oh, yes, that is almost definitely related. It seems that the cached results data couldn’t be deserialized for some reason (maybe it got corrupted, potentially due to special characters?) and the Redis cache backend doesn’t correctly detect that case and still returns a cache hit. Then we get a cache hit back, but without any data, leading to this problem.
You should definitely look for an issue in the Redis module’s issue queue, or create it if there isn’t one already. However, also can’t hurt to guard against this eventuality in our own code. So, glad to hear this helped.

Can someone else confirm that the latest code in the MR works for them? Then I could finally merge this.

We have been using the patch from MR 101 and unable to reproduce the issue since. Hence setting to RTBC.

Great to hear, thanks for confirming!
Merged.
Thanks again, everyone!