Check why some scenarions trigger a "Undefined index warning in buildRealm()" in the Facet API

Problem/Motivation

This is a follow up of this Facet API issue: #1722898: Undefined index warning in buildRealm() on non-search pages.
Under certain circumstances the Facet API integration of Search API triggers a notice like

Undefined index: my_term_facet in FacetapiAdapter->buildRealm() (line 1056 of sites/all/modules/contrib/facetapi/plugins/facetapi/adapter.inc).

While to original issue was about making the code of Facet API more failure tolerant, we should try to figure out how this happens and how we could avoid it on the Search API side.

Possible scenario to reproduce the error

Search API using Search API Views and the whole thing is displayed using panels - this means the facet blocks are assigned to a panels region.
The Search API View has some input validators and processing the query is skipped if the prerequisites aren't met.
If the query isn't processed FacetapiAdapter::addActiveFilters() is not triggered - what means that FacetapiAdapter::$dependenciesPassed is empty.
However, as panels renders the facet block, regardless if the query was executed or not, FacetapiAdapter::buildRealm() is called, what finally throws the notice.

Current state of investigation by cpliakas

Facet API expects that FacetapiAdapter::addActiveFilters() is called prior to any facets being rendered. I probably should have coded the FacetapiAdapter::buildRealm() to throw an error or something to enforce this, but that time has probably passed. Maybe I am misunderstanding the flow, but I see a lot of problems with facets not being initialized prior to rendering. The error is no fun, but if we hid it I fear other problems silently creeping in.

Without panels, the blocks are "rendered" on every page, however there is a check in facetapi_block_view() that simply returns nothing prior to facetapi_build_realm() being called if things weren't initialized properly. The part that is confusing to me is that the FacetapiAdapter::addActiveFilters() invokes the facetapi_add_active_searcher() function. This is the API function that tells Facet API which searches were executed. If you take a look at the facetapi_check_block_visibility() function, which is called by facetapi_block_view(), you will see that it returns FALSE if the API function isn't called.

So to me that means a module must be calling facetapi_add_active_searcher() somewhere. Instead, it should call FacetapiAdapter::addActiveFilters() and all would be right with the world (hopefully).

Proposed resolution

Remaining tasks

User interface changes

none

API changes

none