Cli-microsoft365: UnhandledPromiseRejectionWarning: ParserError: Unexpected token type: Colon, value: :

[sebastianrogers]

1402 # Description

When searching the following error is returned:

UnhandledPromiseRejectionWarning: ParserError: Unexpected token type: Colon, value: :

Steps to reproduce

o365 spo search --query "IsDocument:1" --selectProperties "Path,Author,FileType"

Expected result

Search results are returned

Actual result

(node:572) UnhandledPromiseRejectionWarning: ParserError: Unexpected token type: Colon, value: :
    at Parser.parse (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/node_modules/jmespath/jmespath.js:501:27)
    at Object.search (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/node_modules/jmespath/jmespath.js:1659:25)
    at Function.logOutput (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/dist/Utils.js:114:37)
    at UI.vorpal.pipe [as _pipeFn] (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/dist/index.js:126:32)
    at UI.log (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/node_modules/vorpal/dist/ui.js:436:48)
    at Session.session._log (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/node_modules/vorpal/dist/session.js:93:24)
    at Session.session.log (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/node_modules/vorpal/dist/session.js:78:20)
    at CommandInstance.log (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/node_modules/vorpal/dist/command-instance.js:94:26)
    at SpoSearchCommand.printResults (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/dist/o365/spo/commands/spo-search.js:271:17)
    at then.then (/home/sebastian/.npm-global/lib/node_modules/@pnp/office365-cli/dist/o365/spo/commands/spo-search.js:62:18)
(node:572) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:572) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Environment

• Cloud Shell
  
  
  
  • o365 version: 2.11.0
  
  

[VelinGeorgiev]

Thanks for reporting this Sebastian @sebastianrogers ! We will look into it asap.

[garrytrinder]

Is this issue seen on both PowerShell and Bash consoles? @sebastianrogers

[sebastianrogers]

• bash - yes
• powershell - yes

[waldekmastykarz]

OK, so the issue is that with the introduction of support for JMESPath queries, we used the query option, which was previously used for specifying the search query in the spo search command. So instead the command processing your input as a search argument, it treats it as a JMESPath query. To fix this, we'll need to rename the either option to avoid them colliding. Sorry for the trouble.

@sebastianrogers as a workaround for now, please use the short -q instead of --query.

To minimize the impact of this change (one command vs. all commands), I'd suggest renaming --query in spo search to --searchQuery. The short -q could stay as-is.

[sebastianrogers]

Not a problem, suggest you call it --kql to make it clear what sort of query to use

[waldekmastykarz]

@sebastianrogers thanks for the suggestion. If we supported at some point FQL, would you expect to use a different property or instead add a switch, like --searchQuery 'stuff' --fql?

[sebastianrogers]

No I'd use a --fql property but raise an error if more than one 'native query' parameter was passed.

• Its very explicit, here is my query, its in fql
• If someone relies on the default property 'engine' and you change it then it will break rather than running a kql query with an fql engine

[waldekmastykarz]

You're bringing up an interesting point. Following what you said, using a separate property for KQL and FQL would solve it, because when specifying the query you explicitly specify its format by choosing one property or the other. One thing I'm wondering about though, is what if the user doesn't know the difference between KQL and FQL? Wouldn't it make it too cryptic to expect them to know that what they've been using for all this time (eg. the default search experience) is KQL?

[sebastianrogers]

Understanding your tools is always good.

Explicit is better than implicit unless using a very well known convention.

If you don't know the query language you are using how do you know the syntax is correct?

If the default query language changes this will mean your calls are still valid, with the other way the syntax if parsed may not give you the same results as it did the day before.

When dealing with evergreen systems always be explicit.

[waldekmastykarz]

I understand your point and I agree with it. What I'm wondering about though is to what extent people really understand the technology they use vs. choose the shortest path to success and reuse code fragments they found elsewhere without learning the whole tech stack behind them.

[sebastianrogers]

Just my thoughts but we should aim to raise the standards rather than make tools for fools.

[garrytrinder]

To add my thoughts to this, I have been accustomed to the notion of enabling FQL when searching against SharePoint using the REST API, this is in part due to the way that the SharePoint Search REST API has been implemented over the years.

The Search REST API uses KQL by default, most likely due to FAST historically being an add-on to SharePoint Search rather than part of the core Search service, so was added later to the API, this resulted in having to explicitly state that FQL should be used by passing the enableFql property in the query-string to make it explicit that FQL should be used rather than KQL.

GET http://_server_/_api/search/query?querytext='sharepoint'&enablefql=true

Source: https://docs.microsoft.com/en-us/sharepoint/dev/general-development/sharepoint-search-rest-api-overview#enablefql

It's also worth noting that out of the box web parts have also gone with the KQL approach first historically and this is also true with the way that the PnP Modern Search web parts have been implemented, so again something that people will be accustomed to.

My opinion is that we should follow the REST API, which I think is the most common and widely understood implementation, this provides a solution that would change --query to --queryText solving the conflict with JMESPath, and provide an --enableFql switch for explicitly defining that the query should use FQL.

o365 spo search --queryText "IsDocument:1" --selectProperties "Path,Author,FileType" --enableFql

[sebastianrogers]

A very strong argument @garrytrinder to preserve the 'conventional' way of doing things, but how will it work when a new query language is introduced?

The idea of using -queryText to avoid clashing with JMESPath is nice and does preserve some continuity.

[VelinGeorgiev]

I think the suggested by Garry is what I as SharePoint developer 😄 would expect to see as options.
--queryText makes sense in absence of the reserved for JMESPath --query.
--enableFql is a flag that clearly identifies what we are after. I assume this flag will be used by users already familiar with the search apis and they would look for such flag since it is similar to the APIs. To Sebastian's point of new query language, I do not think we should bother with this at the moment simply because this is not even on the roadmap and might never be introduced.

[sebastianrogers]

Sounds good to me