hmmwhatsthisdo
commented
6 years ago The offending code appears to be this snippet in Invoke-JiraMethod's exception-handler:
https://github.com/AtlassianPS/JiraPS/blob/2a53f7cbf12cc0b2afbc46d7146783228121cb22/JiraPS/Public/Invoke-JiraMethod.ps1#L123-L129
In the event $WebResponse.ErrorDetails is non-null (and thus casts to $true), $responseBody is assigned within the exception handler.
Further down, within the error-parser itself, the only opportunity for $result to be assigned is within this if-block:
https://github.com/AtlassianPS/JiraPS/blob/2a53f7cbf12cc0b2afbc46d7146783228121cb22/JiraPS/Public/Invoke-JiraMethod.ps1#L146-L158
As $responseBody is already set, the expression is false and the block is not executed.
In the event a response from the Jira API throws an exception out of
Invoke-WebRequest(as is normal with HTTP 4xx/5xx response codes), the presence of message data in theErrorDetailsfield can cause error-handling code inInvoke-JiraMethodto malfunction.Expected Behavior
API errors should be propagated out of
Invoke-JiraMethodback to the user (or calling cmdlet).Current Behavior
API error exceptions with non-null
.ErrorDetailsfields generate warnings indicating the API returned an error status, but do not return the errors themselves.Notes
The presence/lack of data in the
ErrorDetailsfield may be due to usage of chunked transfer encoding - see this PowerShell UserVoice post detailing a similar issue. If Apache Tomcat uses chunked encoding by default (whereas individuals using an application proxy like IIS ARR or NGINX), this may explain some of the erratic behavior.