Unable to render EntityFields in views with search_api_opensearch

Having the same issue, it also throws an exception when using a rendered entity because isValidDatasource is called with an array rather than a string which throws an exception.

EDIT: Should mention patch #5 fixed it for me :)

I'm having the same issue, and patch #5 does solve the issue for me too.

I wonder if we could avoid the duplication of configured fields a bit by adding a getLazyLoadFields() method or some such to ResultRow instead of re-creating the array in SearchApiQuery?

I mention because the solution used in patch #5 is used once already in SearchApiQuery::addField(), so we're duplicating this twice in the same file...

  public function addField($table, $field, $alias = '', array $params = []) {
    // Ignore calls for built-in fields which don't need to be retrieved.
    $built_in = [
      'search_api_id' => TRUE,
      'search_api_datasource' => TRUE,
      'search_api_language' => TRUE,
      'search_api_relevance' => TRUE,
      'search_api_excerpt' => TRUE,
    ];
    if (isset($built_in[$field])) {
      return $field;
    }
...

I think this is the best approach which brings the two existing methods together with minimal impact on additional classes and methods.

There are only 2 calls to getFields() methods in the SearchApiQuery class so I think this covers all use cases for now.

Does that mean these fields shouldn't be indexed in the first place? If so we can simply stop search_api_opensearch indexing them here

@acbramley That might also be the case. Either way this patch still seems necessary, they're not fields that views should be querying.

It might be worth referring comment #11 back to #3267797: Indexed Fields in views empty, to see if any work is actually needed there.

#10 works for me

@pebosi could you mark as reviewed pls? (assuming you have)

The patch at #10 works fine.
The code is pretty straightforward and I am marking it as reviewed.

Rerolled

Reroll, the list() change was already committed.

I found this issue via #3313519: TypeError: Illegal offset type in isset or empty in Drupal\search_api\Entity\Index->isValidDatasource() when using rendered item field

What is the purpose of putting search_api_id, search_api_datasource and search_api_language into the index in the first place? An alternative fix is to skip indexing these items at all in the OpenSearch case, and that seems to work with no side effects for my use case.

Thanks a lot for posting this, and sorry it took me such a long time to reply.

The patch looks pretty good and the problem seems real, based on the feedback. (I’m not using the Search API OpenSearch module myself.)
Also, indexing those fields migth be necessary, as \Drupal\search_api\Query\QueryInterface::sort() specifies that it should be possible to sort by them. (Filtering by language or datasource is also allowed.) In my opinion, the returned result items should still not include those fields (as they are not configured fields on the index), so a fix to the Search API OpenSearch module might be in order, too, but it definitely cannot hurt to guard against this problem here, too.

However, if $this->ignoredFieldValues is never written to anyways, couldn’t it just be a constant?
Furthermore, why not just make \Drupal\search_api\Plugin\views\ResultRow::$lazyLoad public (or a constant) and use that directly?
Patch attached, please review. (Would probably need a change record, too, though, in this form, due to the deprecation of \Drupal\search_api\Plugin\views\ResultRow::$lazyLoad. (Only relevant for any sub-classes of \Drupal\search_api\Plugin\views\ResultRow, but still.)

+1 RTBC #19

Using search_api and search_api_opensearch with this patch resolved the fatal errors that were happening on search.

Thanks for testing and reporting back, good to hear this worked! (And even fixed a fatal error, in your case!)
Committed the patch and posted a change record.
Thanks again, everyone!