Receiving "Underlying input stream returned zero bytes" from ExtractVariables policy accessing ServiceCallout response

scase
Participant III

We have a proxy which does a service callout to get an authentication token and dynamic target endpoint from a vendor. The response payload from this callout looks something like this:

{"authToken":"<auth string>","issuedAt":1457015976996,"endPoint":"https://<endpoint url>"}

In trace, we see the callout getting a 200 and bringing back the expected payload. We are also able to load this payload into cache using a PopulateCache policy. On subsequent runs, this cached value can be accessed successfully by a LookupCache policy followed by another ExtractVariables policy.

When we make that initial callout, though, we are seeing this:

{
  "fault": {
    "faultstring": "Underlying input stream returned zero bytes",
    "detail": {
      "errorcode": "Internal Server Error"
    }
  }
}

Which I believe is a Java IO error. Here is the snippet we use to get the values:

<JSONPayload>
    	<Variable name="authToken">
    		<JSONPath>$.authToken</JSONPath>
    	</Variable>
    	<Variable name="resEndpoint">
    		<JSONPath>$.endPoint</JSONPath>
    	</Variable>
    </JSONPayload>

Which we do in the same way for both the ServiceCallout and LookupCache.ExtractVariables policies.

We have done quite a few of these patterns in our other APIs so I'm a little stumped. All I can think is that something about the payload is difficult to read directly as JSON, but this ends up getting cast or transformed when that payload is stored into cache--but I'm not sure that makes any sense.

Any insights would be quite helpful.

0 4 1,514
4 REPLIES 4

Former Community Member
Not applicable

Hi @Sean Case this reminds me of a similar situation I was running into. Is this happening consistently or sporadically? Are you sure sometimes the URL invoked by the ServiceCallout policy does not return any HTTP 3xx (307 etc) redirects instead of a 200? This could also happen if the service is taking a long time to respond. Have you run a curl command (--verbose) directly against the URL & see what kind of response is received?

scase
Participant III

We were suspecting that the response body and close connection from the ServiceCallout were getting out of synch, but the vendor couldn't confirm anything. It does eventually get here, though and the value ends up getting cached for subsequent requests. When using cUrl, we get a response back successfully, but we think that a simpler tool like that may be a little more forgiving than our proxy flow (as it's trying to read values from the response object).

In @Sean Case's case, the endpoint is indeed returning a 200 OK plus a JSON payload each and every time, and very quickly.

I've noticed that, in the Trace utility, the failing Service Callout lists several Properties multiple times. For example: ServiceCallout.response is listed twice, as are several other Properties like "stepDefinition-async" and "stepDefinition-continueOnError." For the "ServiceCallout.response double-listing, in all cases the first one is blank yet the second one contains the correct JSON (confirmed via cURL as well).

So it almost seems like the Callout is being executed twice, but the first response (the "bad" one) may be causing the problem. Is there anything that may cause the Callout to be executed twice?

I can't share the Bundle or even the tokens for security reasons, but am trying to determine the above.

Thanks.

There were a lot of Conditionals which made viewing this confusing. I confirmed the callout is being executed only once.

The error is related to parsing JSON on the response, and we are working on a fix.

Thanks.