"can not use FieldCache on multivalued field" error when using boost recent dates processor

Before we continue here, are you sure that you are using the scheme this module provides? Or could it be that you're using Solr's default managed schéma?

The schema used is the one provided by this module. The issue is also present when using Acquia-provided config (Latest) Drupal 8 / 9 - Search API Solr 4.2.0 - Solr 7 - [drupal-4.2.0-solr-7.x-0] - v1.0.

This resolves the issue we were having with the boost processor – can we get the MR approved?

The minimum required schema version currently is 4.2.8, not 4.2.0.

Regardless if the patch avoids that error or not, you have an issue in your entity model.
It makes no sense to boost on most recent dates if you randomly pick one out of multiple.

For example, if you store 1980 and 2023 in these fields, the entity will be shown at the end of the results if 1980 is select or on top of the list when 2023 is selected.

You need to implement that selection by yourself.
You can define an additional sine valued filed on the entity and store the most recent date in it on entity save.

Or you can. Add a dummy field to the index and do that calculation in a Search API Solr pre index event.

Or you can implement a Search API processor to do it.

But I know that we have that stupid hack for sort fields to compatible to the database backend, just to avoid errors in views regardless that the result might be wrong.
But the database backend can't boost on dates. So it is a question if we really should repeat the same erroneous approach here or if the exception is correct to inform you about issues in your data model.

At least the patch should be extended to log an error if someone tries to boost on a multi valued field.

Thanks for the input @mkalkbrenner. In our case the date boost works by using search_api's aggregated field mechanism to select the last encountered value of either created or field_date_published (a field that is present only on certain specific entity types, so if present the aggregate field takes its value). The resulting dm_field_sort_date is therefore a single-valued field, and the data model is sound for our purposes. The underlying issue seems to be that fields are given a dm_ prefix, regardless of whether they are actually multi-valued or not. A solution might be for the aggregated field tool to name and type fields according to their cardinality.

Thanks @cbrody for that explanation. So your data model seems to be fine.

But the bug fix should be something else. We have a detection for that cardinality. Maybe it doesn't work correctly for that use-case and needs to be fixed.

But could you please verify the 'Fallback to multiValued field types' setting in the advanced options of the Search API Server Backend config?
Maybe it is turned on in your installation.

We've tested with 'Fallback to multiValued field types' enabled and disabled and the error still appears with the unpatched module.

Thanks for checking this.

So the error must be here in SearchApiSolrBackend::formatSolrFieldNames():

if ($field->getDataDefinition()->isList() || $this->isHierarchicalField($field)) {
  $pref .= 'm';
}
else {
   try {
     // Returns the correct list of field definitions including
     // processor-added properties.
     $index_properties = $index->getPropertyDefinitions($field->getDatasourceId());
     $pref .= $this->getPropertyPathCardinality($field->getPropertyPath(), $index_properties) != 1 ? 'm' : 's';
  }

Either that aggregated field is erroneously declared as list or as hierarchical field or getPropertyPathCardinality() returns a wrong result.
@Finn Lewis could you debug that?

Can we check if the aggregated field is single or multivalued rather than just relying on the is_list property?

The perfect solution would be to fix that in Search API, for example by providing a dedicated aggregated field for union.
In Search API Solr we can't skip the check for lists because it is also required for other fields.
So what we can do in Search API Solr is to add a check before we check for lists. If it is an aggregated field we could read its config and check for single value aggregations.

This patch works in combination with https://www.drupal.org/project/search_api/issues/3340305#comment-14940876 to ensure the field prefix for aggregated fields works correctly.

The patch looks good. But ideally we can extend the existing test for field names.

That change will require to deploy a new config-set to Solr and to re-index. Therefore the required minimum schema version needs to be raised.

Search API 1.29 contains the required counterpart. I'll raise the minimum version requirement for Search API and the schema version for the next release and include this patch.