Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Input value "f" contains a non-scalar value.

Everything worked fine in D9, started facing issues after D10 upgrade.

I'm having the same issue after upgrading to D10. It is related to Facets module not being able to process array in GET request when running search filters:
Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Input value "f" contains a non-scalar value. in Symfony\Component\HttpKernel\HttpKernel->handle() (line 83 of /var/www/html/docroot/vendor/symfony/http-kernel/HttpKernel.php).

This is not a Search API Solr issue but a facets issue.
In fact it is an incompatibility with newer symfony versions that has been fixed in facets 3.x

@mkalkbrenner I want to believe you, but upgrading to Facets 3 did not help me, deleting the facet block did not help, and indeed uninstalling Facets module did not help. I am still getting the error without Facets installed. So this cannot be just a Facets issue.

I did however find that the exposed filter works correctly in the Views preview, just not in the rendered page. So perhaps it's a problem with core Views or one of my other Views modules and not a Search API Solr issue. I'll see what I can find out tomorrow, and when I have an issue that this is a duplicate of, I will change it back to Closed (duplicate).

OK, thanks for keeping us informed.

The problem is in a Symfony 6 component with the unenviable name of "InputBag." As documented at https://stackoverflow.com/questions/77230889/how-do-i-fix-symfony-6-erro... , anyplace in the code that calls `$form->submit($request->request->get($form->getName()));` needs to now say `$form->submit($request->request->all($form->getName()));` or it will throw this error.

In my case, the offending code turned out to be in smart_date_recur module, so I'm marking this as a duplicate of a new ticket, https://www.drupal.org/project/smart_date/issues/3414404 🐛 BadRequestHttpException: input value contains a non-scalar value Active

However, there are very likely other modules that are using get() instead of all().

Thank you @BenStallings!!

I just ran into this 2 minutes ago and your comment was very timely! Changing from get() to all() did indeed fix it.

Thanks @BenStallings

In my case, I had a problem with facets in my custom code, which was called like this:

$request->query->get('f')

So, I changed it to this, and it works:

$request->query->all('f')