Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better rest error handling for 5.1 #33

Open
insomniacc opened this issue Mar 21, 2023 · 5 comments
Open

Better rest error handling for 5.1 #33

insomniacc opened this issue Mar 21, 2023 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@insomniacc
Copy link
Owner

If using core you'll get a relevant error from a bad rest request including the error message.
example:

Invoke-RestMethod: 
Line |
2265 |              $Response = Invoke-RestMethod @RestSplat
     |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | {"result":{"errCode":"42202","errMsg":"This item cannot be submitted for multiple people as it is not configured with Requested For"}}

On 5.1 errors are basic and messages not displayed:
example:

Invoke-RestMethod : The remote server returned an error: (400) Bad Request.
+ ... $Response = Invoke-RestMethod -Method POST -Uri $URI -Headers $Header ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

Enhancing the error handling and output would be a better user experience on 5.1

@insomniacc insomniacc added the enhancement New feature or request label Mar 21, 2023
@insomniacc
Copy link
Owner Author

insomniacc commented Mar 21, 2023

The error on core comes from the response body nested under result. On 5.1 only the typical header error is shown not the response. It would be useful to parse these and display them correctly for both core and 5.1

@insomniacc insomniacc changed the title Better rest errors on PS5.1 Better rest error handling Mar 21, 2023
@insomniacc
Copy link
Owner Author

Also needs checking all commands should throw a readable exception if there are permission/authorization errors.

@insomniacc insomniacc modified the milestones: 2.0.0, 1.0.1 Mar 27, 2023
@insomniacc insomniacc self-assigned this Mar 27, 2023
@insomniacc insomniacc modified the milestones: 1.0.1, 1.1.0 Mar 27, 2023
@insomniacc
Copy link
Owner Author

I've forced an error in 5.1 (400 bad request), checking the full exception object from both invoke-webrequest and invoke-restmethod still doesnt show any further detail than this.
Not sure what the difference between that and core is, with core I'm getting

{"error":{"message":"Pagination not supported","detail":"The requested query is too long to build the response pagination header URLs. Please do one of the following: shorten the sysparm_query, or query without pagination by setting the parameter 'sysparm_suppress_pagination_header' to true, or     
                        set 'sysparm_limit' with a value larger then 621 to bypass the need for pagination."},"status":"failure"}

Under the ErrorDetails inside the exception. I think it's not going to be a straight forward one so I'll leave this for now.

@insomniacc insomniacc removed this from the 1.1.0 milestone Apr 5, 2023
@insomniacc insomniacc changed the title Better rest error handling Better rest error handling for 5.1 Apr 5, 2023
@liamjpeters
Copy link

liamjpeters commented Apr 24, 2023

Hey Tom 👋,

5.1 will stop short of reading the full response body when it gets an error and will instead just read the headers. If, as in the case of ServiceNow, those headers don't contain too much useful info - you can get to the full response stream and decode it yourself by doing something like:

try {
  # ServiceNow Failing Rest Call Here
} catch {
  $StreamReader = New-Object System.IO.StreamReader -argumentList ($_.Response.GetResponseStream());
  $ErrorBody = $StreamReader.ReadToEnd()
  $StatusCode = [int] $_.Exception.Response.StatusCode
  $StatusDescription = $_.Exception.Response.StatusDescription + " " + $ErrorBody
}

I've not tested the above (it's from an old ServiceNow script of mine actually) but it should point you in the right direction.

Cheers

@insomniacc
Copy link
Owner Author

@liamjpeters Hey, thanks for this comment, interesting, I'll take a closer look this next week, haven't unfortunately had much chance of late! Hope things are going well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants