🇷🇴Romania @Rares Badita

The issue arises when creating a URL from a request using the Url::createFromRequest($request) method.
When the Router class tries to match the url of the $request parameter to a route, we reach this code:

// Check HTTP method requirement.
if ($requiredMethods = $route->getMethods()) {
  // HEAD and GET are equivalent as per RFC.
  if ('HEAD' === $method = $this->context->getMethod()) {
    $method = 'GET';
  }

  if (!in_array($method, $requiredMethods)) {
    $this->allow = array_merge($this->allow, $requiredMethods);
    $routes->remove($name);
    continue;
  }
}

The problem is that the $method used to check against $requiredMethods is not obtained from the current $request, but from $context, which is the original request from the request stack.

This leads to an issue with REST exports that use the Facets serializer view style. When building the facets results, FacetsUrlGenerator::getUrlForRequest() wants to create a URL from a request to the actual view display(made with GET), not to the preview form(made with POST), thus resulting in a method mismatch and an exception being thrown.

I've added a patch for the Facets module to catch this exception.

I've also changed the issue project from views-ui to facets.

I've updated the patch to use Drupal\search_api\LoggerTrait;

I've tinkered a bit with the issue, and I think the behaviour used for processing the form when contextual filter are present should be also used when there are no contextual filters.

Rares Badita → created an issue.

Rares Badita → created an issue.

Great :D

Fair enough, the fact that this suddenly flips on aggregation is a little unexpected, but does this stop them from making it valid?

Technically no. If you account for the 'ORDER BY' fields when computing the non-aggregate fields (or if there is no 'ORDER BY' clause) the query stays valid and returns the same values. The difficult part here would be to programmatically account for the fields, since I did not find an easy way to modify the non-aggreates after they are computed and before the query execution.

So the actual fix here might be to not flip on aggregation when adding a having?

This would be a good fix as well, but it is kept for legacy purposes as you mentioned. I cannot find if the 'GROUP BY' clause was mandatory for 'HAVING' in older versions of SQL, but I suspect that's the reason.

Rares Badita → created an issue.