I help maintain a site (drupal 8.9.1, search api v 8x.1.17) that relies on the Search API for its search functionality. The site's search currently works. However, various updates and improvements to the site periodically raise a strange problem: after a code push, the search functionality occasionally (and seemingly randomly) breaks. I am currently trying to assess why this is the case and am hoping to fix the issue.

Here's my best description of the problem. Whenever this problem arises, when a user issues a search, the search API retrieves a list of 10 empty "search results." The resulting SERP says it is displaying results 1-10 and allows the user to page through the next 10 results; these also are empty.

As I mentioned, the search is currently working correctly. This is because I have rolled back any changes that raise this problem. However, this isn't a sustainable strategy. N.B. The changes that raise the problem often have nothing to do with search, to the best of my knowledge. For instance, adding a custom module with some hook_cron functionality for something unrelated last week caused the search to break.

My sense is that this problem has to do with the "view" that the Search API relies on to display search results. I say this because it appears that the back-end processes (e.g. query handling, hitting the index, sorting results) work fine; it's only the actual delivery of hit nodes that is failing.

Adding to the confusion, when the site was initially designed (before I joined the project), the designers created a custom module that implements several views-related hooks. My intuition is that the bug is arising in this custom module.

Having said all this, my question is: can anyone shed any light for me on how a set of search results from Search API module make their way from the solr core to the user? For instance, any insight on which hooks are involved and what role they play in the delivery of search results would be very helpful.

Obviously, I can't hope for help with this custom module. But it would be awesome if folks could help me learn how the Search API integrates with views to display query results.

Comments

mefron created an issue. See original summary.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Active » Fixed

Sorry for not getting back to you sooner. I hope this is still relevant.

Anyways, with a view, the central class is \Drupal\search_api\Plugin\views\query\SearchApiQuery, which creates the search query, executes it and then creates the array of Views result rows in \Drupal\search_api\Plugin\views\query\SearchApiQuery::addResults(). From your description, it seems things are working fine until then.

One thing that might happen then is that we fail to load the underlying entities for result items, in \Drupal\search_api\Query\ResultSet::preLoadResultItems(). Not sure how that might happen, but it’s possible. (They then wouldn’t turn up anymore in any searches, though, until you rebuild the tracker. So that’s probably not it.)

After that, the question is how you have configured your view. Do you use the “Fields” or the “Rendered entity” row style? In the latter case, this would use the \Drupal\search_api\Plugin\views\row\SearchApiRow row plugin class, which then uses the configured view mode to render the result entity (see \Drupal\search_api\Plugin\views\row\SearchApiRow::render()). This sounds like the most likely to fail, I guess, as entity viewing is a rather complex process. So that would be my best guess for starting to debug. (If the code doesn’t even get there, you need to track back.)

I hope this helps! Otherwise, or if more questions arise, please feel free to re-open.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.