Hi everyone,

I was hoping someone could help us solve an issue we've been experiencing lately.

So we get the following error when calling an API:


I know the line doesn't necessarily represent the error but here is a screenshot of line 7091:


 I'll say what we've tried/noticed and maybe someone will come up with some other way to troubleshoot this issue:

- When calling it using Postman (or some other API testing tool) it is executed successfully;

- The response code is 200;

- We checked the JSON format and it's valid;

- We tried adding the OnAfterResponse action and the moment it exits this action we get this error.

- It happens the moment we're done calling the API so even if we don't assign the output of the API to anything it will still happen;

- We've recreated the method with the payload response we get when there is a parse error and we still face the same issue;


Thanks in advance.

Hi Ricardo,

It seems whatever the JSON is, it can't be parsed properly by the Platform. All other information you give it constistent with that:

- Postman doesn't ;heck the JSON for validaty, afaik.

- OnAfterReponse is executed before the JSON is parsed;

- Parsing is always done, even if you don't use the output.

Since you haven't included the JSON, it's difficult to say what causes this. Can you add the JSON to a post?

At least one thing you could try is check what happens if you parse the JSON with the JSON Deserialize Statement (). Sometimes this works while the REST deserialization doesn't work. If that's the case, you could try, as a workaround, deserializing/serializing the JSON in the OnAfterResponse.


Hi Kilian,


Thanks for the reply. After further analysis I noticed that I got a hold of the wrong JSON and the correct one was in fact cut at line 7091 so the JSON wasn't correctly closed hence the error. I know that some of the APIs we are consuming are streamed, so in other words large responses are sent in chunks, could this be the problem? If so, is there a way I can handle these type of responses with OutSystems?



Hi Ricardo,

Not sure what you mean by "streamed", never heard of this in combination with a REST service. Also never heard of REST responses being sent in chunks, so I'd find that highly unusual. It would make the response invalid JSON (as you've experienced).

Kilian Hekhuis wrote:

Hi Ricardo,

Not sure what you mean by "streamed", never heard of this in combination with a REST service. Also never heard of REST responses being sent in chunks, so I'd find that highly unusual. It would make the response invalid JSON (as you've experienced).

This is regarding "Transfer-Encoding: chunked" on the HTTP Post request. In this post HERE the same question was asked but no answer.

I woudl find it pretty moronic to have a REST service with that transfer encoding...

Unfortunately, that's what we have here at the client. What I notice is that Outsystems only gets the first chunk which is obviously incomplete resulting in an invalid JSON format. 

My question is: Is there a way to force the platform to "wait" for the last chunk? 

There is no "wait". For each chunck you'll have to do a new call. Is there a way to determine what the last chunck is? If so, you could store each chunck in a temporary record in the database, and on receiving the last one, add the chuncks together (use the StringBuilder actions from the Text extension) and use JSON Deserialize to convert the JSON to OutSystems Structures.

Hi Ricardo,

I'm also thinking in the same direction as Kilian. According to the description below, you continue to append the chunks together, until a chunk comes along that starts with (length) '0':
"Data is sent in a series of chunks. The Content-Length header is omitted in this case and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format, followed by '\r\n' and then the chunk itself, followed by another '\r\n'. The terminating chunk is a regular chunk, with the exception that its length is zero. It is followed by the trailer, which consists of a (possibly empty) sequence of entity header fields."

Regards,

Lennart