Open IvanTheBearable opened 1 year ago
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
A bit more info... it turns out the problem only occurs if the value is a number. i.e. This works fine:
"results": [
"RefinableString113:Test"
]
So, it looks like the API is converting the value into a number which then doesn't match when filtering a string property. Seems reasonable to me. The FQL documentation already advises to quote all strings to avoid conflicts with reserved words. But it doesn't require it, so this is still a backwards compatibility issue.
Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
SharePoint REST API
Developer environment
macOS
What browser(s) / client(s) have you tested
Additional environment details
Problem identified using the PnP Modern Search web part (v4.7). Problem reproduced, and workaround verified, using SharePoint Search query Tool v2.10.0.
Describe the bug / error
Sending a query to the search API (/_api/search/query or /_api/search/postquery) with an unquoted refinement filter has stopped working. For example, up until this month, the following query worked:
Then, sometime around the end of October or beginning of November, this query stopped returning result. It doesn't error, it just returns no results.
The fix is to wrap the filter value in quotes like this:
This returns the expected results. The FQL documentation indicates that quotes are not required unless there is a space. Yes, they are recommended, and maybe should be required, but right now this causes some backwards compatibility issues.
Steps to reproduce
Send a postquery to the search api using a string refinement filter with no spaces, not wrapped in quotes. Similar to the example above (but with parameters modified to return results in your environment):
Expected behavior
Search results filtered by the supplied refiner value.