Fatal error on full text search after removing a field from the index

I don't think that this is the correct fix. There must be a reason why the $document is NULL. That's the real bug and your patch just hides it.
Can you provide further information or a stack trace?

This is happening to us currently because we removed a field from the index I think.

Full stack.

Notice: Undefined index: field_planogram_description in ./web/modules/contrib/search_api_solr/src/Plugin/search_api/backend/SearchApiSolrBackend.php on line 885
The website encountered an unexpected error. Please try again later.
Error: Call to a member function getBoost() on null in Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend->search() (line 886 of modules/contrib/search_api_solr/src/Plugin/search_api/backend/SearchApiSolrBackend.php).
Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend->search(Object) (Line: 450)
Drupal\search_api\Entity\Server->search(Object) (Line: 464)
Drupal\search_api\Query\Query->execute() (Line: 433)
Drupal\search_api\Plugin\views\query\SearchApiQuery->execute(Object) (Line: 1412)
Drupal\views\ViewExecutable->execute(NULL) (Line: 1440)
Drupal\views\ViewExecutable->render() (Line: 171)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1616)
Drupal\views\ViewExecutable->executeDisplay('page_1', Array) (Line: 78)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func(Array, Array) (Line: 376)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 149)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
include('./web/index.php') (Line: 36)

Maybe we're getting closer now. Does the error go away when you re-index?

Nope, from what I can tell, in, SearchApiSolrBackEnd:890

$search_fields = $this->getQueryFulltextFields($query); //is returning fields that have been deleted from the index in the ui

I was additionally running into this separate issue which was fixed, by using the work around. Disabled and enabled the index. They may be related.

https://www.drupal.org/node/2749101

edit: ps, I'm on this until it's fixed, I'm around in irc @ justAllgood or allgood on the slack if you want to debug in real time.

thanks for that information. I move this issue to Search API because it seems to be caused there.

I was able to find I think, the reason the error is caused.

In my views.view..yml which was using our search index, I found found a reference to our full text search filter. It seems if you delete the field, the reference to the field sticks around. Example: yml below:

filters:
        search_api_fulltext:
          id: search_api_fulltext
          table: search_api_index_content_and_media_index
          field: search_api_fulltext
          relationship: none
          group_type: group
          admin_label: ''
          operator: or
          value: ''
          group: 1
          exposed: true
          expose:
            operator_id: search_api_fulltext_op
            label: Search
            description: ''
            use_operator: false
            operator: search_api_fulltext_op
            identifier: search_api_fulltext
            required: false
            remember: false
            multiple: false
            remember_roles:
              authenticated: authenticated
              anonymous: '0'
              administrator: '0'
              store_manager: '0'
              author: '0'
              publisher: '0'
              general_counsel: '0'
          is_grouped: false
          group_info:
            label: ''
            description: ''
            identifier: ''
            optional: true
            widget: select
            multiple: false
            remember: false
            default_group: All
            default_group_multiple: {  }
            group_items: {  }
          parse_mode: phrase
          min_length: null
          fields:
            title: title
            body: body
            name: name
            name_1: name_1
            alternate_name: alternate_name
            field_planogram_description: field_planogram_description

Removing field_planogram_description: field_planogram_description and running config-import (or removing the filter from views_ui, I assume) cleared up the issue.

Hm, yeah, I guess it makes sense to validate the input there, by default, and only return fulltext fields that are actually known for the index. Backends with other supported fulltext fields can still override the method to add those, too.

Patch attached, along with a test case. Please test/review whether it fixes this problem!

A second step in fixes this would probably be to update views if an index is edited – but that's a lot more work, and pretty tricky, I'd say, so fixing the fatal error should be good enough for now. (It's probably even debatable if we should really go around adapting other modules' configuration like that.)

Come to think of it, fixing this in the Views fulltext filter plugin would also have been an option. But I guess this is the "safer" fix, also making sure this is handled correctly for, e.g., Search API Pages.

(Any idea why this doesn't trigger the test bot?)

Above patch appears to be working for me.

I like this, the code is simple and it has good test-coverage, @drunken monkey++

Good to hear, thanks for testing and reviewing!
Committed.
Thanks again, everyone!