The SearchApiViewsQuery tries to load the entities based on the data returned from a search, but if no matching entities are found in the Drupal database, the returned array will contain a NULL element for each missing entity that existed in the search result.

This leads to the following error which terminated the entire drupal request, when the output from the get_result_entities() method are used as argument for entity_view():
EntityMalformedException: Missing bundle property on entity of type .... in entity_extract_ids() (line 7643 of ...../includes/common.inc).

This is because entity_view() expects an array of proper entity objects, and cannot handle NULL elements.

CommentFileSizeAuthor
#3 search_api-failure_on_non_existing_solr_results_in_views-1988238-3.patch1.26 KBesbenvb
#1 search_api-failure_on_non_existing_solr_results_in_views-1988238-1.patch646 bytesesbenvb

Comments

esbenvb’s picture

esbenvb commented
StatusFileSize
new search_api-failure_on_non_existing_solr_results_in_views-1988238-1.patch646 bytes

This patch fixes the problem by only adding valid entities to the result array.

IMPORTANT! When you port the patch, be sure to supply the correct attribution when doing the GIT commits, as described here:
http://drupal.org/user/989064

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Component: Plugins » Views integration
Status: Needs review » Needs work

Thanks for reporting and preparing a patch!
Usually, this should not happen, but I agree that when it does an error screen is not the appropriate response. (Though I wonder why, in this case, Views doesn't automatically catch the exception, which it usually does unless I'm mistaken.)
We might consider additionally logging a warning or error when an item is excluded this way, but other than that your patch looks good to me. Please add a watchdog() call and when no-one objects I'll commit this.

IMPORTANT! When you port the patch, be sure to supply the correct attribution when doing the GIT commits, as described here:http://drupal.org/user/989064

If you had taken a moment to check, you'd seen that I always do that. No need to capslock at me.

esbenvb’s picture

esbenvb commented
StatusFileSize
new search_api-failure_on_non_existing_solr_results_in_views-1988238-3.patch1.26 KB

Thanks for the quick reply!

Good idea with a line in the watchdog when this happens - I've made a new patch, hope you like it...

Don't take my note about attribution personal, I add it every time I post a patch, because my experience is that a lot of people forget it... I'm glad to hear you don't :)

esbenvb’s picture

esbenvb commented
Status: Needs work » Needs review

Changed status

drunken monkey’s picture

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

Thanks. I adapted the patch a bit to get rid of the duplicate code, and then committed it.

Don't take my note about attribution personal, I add it every time I post a patch, because my experience is that a lot of people forget it... I'm glad to hear you don't :)

If you add this to all posts with patches, it's even more important to phrase it properly. Right now, in my opinion, it sounds a bit … overbearing? If you get rid of the caps and use “please”, people will probably react better to it. E.g., try something like this:

I haven't checked whether you do this already, but if you're committing this patch, please remember to supply the correct attribution in the Git commits (as described here).

Status: Fixed » Closed (fixed)

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