You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you specify the -RetryCount parameter of the Submit-PnPSearchQuery and set it to anything other than 0, the query is not retried, but after 5 seconds an empty result set is returned.
Expected behavior
I expect that the query is retried the number of times specified in the -RetryCount parameter and if all retries fail, the Exception of the last retry is thrown.
Like this:
Actual behavior
The query is set to be retried only once, but instead of the exception, an empty result set is returned:
Steps to reproduce behavior
Run Submit-PnPSearchQuery with a query that will fail (e.g. specify a non-sortable managed property in the sort list) and the -RetryCount parameter set to anything other than 0, specify the -Verbose parameter to see what's happening.
What is the version of the Cmdlet module you are running?
2.99.146
Which operating system/environment are you running PnP PowerShell on?
Windows
Linux
MacOS
Azure Cloud Shell
Azure Functions
Other : please specify
Possible cause
I debugged the cmdlet to see what's happening and it looks like the reuse of the KeywordQuery instance is causing this. Currently it is implemented like this:
KeywordQuerykeywordQuery=CreateKeywordQuery(clientFunction);keywordQuery.StartRow=startRow;keywordQuery.RowLimit=rowLimit;varsearchExec=newSearchExecutor(ClientContext);// We'll always try at least once, even if RetryCount is 0 (default)for(variterator=0;iterator<=RetryCount;iterator++){try{varresults=searchExec.ExecuteQuery(keywordQuery);ClientContext.ExecuteQueryRetry();
...
Because the same KeywordQuery intance is reused throughout the loop, the query is not executed the second time, throws no Exception and simply returns an empty resulttable.
If you recreate the KeywordQuery instance for each retry iteration, it does work:
varsearchExec=newSearchExecutor(ClientContext);// We'll always try at least once, even if RetryCount is 0 (default)for(variterator=0;iterator<=RetryCount;iterator++){try{KeywordQuerykeywordQuery=CreateKeywordQuery(clientFunction);keywordQuery.StartRow=startRow;keywordQuery.RowLimit=rowLimit;varresults=searchExec.ExecuteQuery(keywordQuery);ClientContext.ExecuteQueryRetry();
...
The text was updated successfully, but these errors were encountered:
Reporting an Issue or Missing Feature
If you specify the
-RetryCount
parameter of the Submit-PnPSearchQuery and set it to anything other than 0, the query is not retried, but after 5 seconds an empty result set is returned.Expected behavior
I expect that the query is retried the number of times specified in the

-RetryCount
parameter and if all retries fail, the Exception of the last retry is thrown.Like this:
Actual behavior
The query is set to be retried only once, but instead of the exception, an empty result set is returned:

Steps to reproduce behavior
Run Submit-PnPSearchQuery with a query that will fail (e.g. specify a non-sortable managed property in the sort list) and the
-RetryCount
parameter set to anything other than 0, specify the-Verbose
parameter to see what's happening.What is the version of the Cmdlet module you are running?
2.99.146
Which operating system/environment are you running PnP PowerShell on?
Possible cause
I debugged the cmdlet to see what's happening and it looks like the reuse of the
KeywordQuery
instance is causing this. Currently it is implemented like this:Because the same KeywordQuery intance is reused throughout the loop, the query is not executed the second time, throws no Exception and simply returns an empty resulttable.
If you recreate the
KeywordQuery
instance for each retry iteration, it does work:The text was updated successfully, but these errors were encountered: