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

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/finnlearn_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.
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!

The last submitted patch, 15: 3321499-15--follow-up--views_errors_when_query_is_null.patch, failed testing. View results →

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.