JSON parse error: Unexpected character ('n' (code 110)): was expecting comma to separate Object entries

We have a test where we pass a JSON object to an endpoint object. The object created in katalon studio passed the JSON object right on through to the endpoint

This test is passing when run in Katalon 6.3.0.rc7, but if we run it in Katalon 6.3.3 it fails with the error message

JSON parse error: Unexpected character ('n' (code 110)): was expecting comma to separate Object entries

To be clear, the enpoint of our microservice is throwing this error, and Katalon fails the test when the api call returns a 400 instead of a 200ā€¦

To me it looks like the message being sent to the endpoint is not identical. It seems extra characters are being added to the request object before it leaves Katalon.
Is anyone experiencing this problem?
Is there a way to have the request object printed out so I can see what is actually being sent?

You can see requests and their properties in the DevTools Network panel.

You should consider upgrading to the latest release.

what else would you expect?
i suggest to add a verification (or two) in katalon before any attempt to parse the response:

  • response code 200
  • response is json

The problem is that the test passes with a 200 in 6.3.0, but i get a 400 in 6.3.3.
Nothing else changes. The test does not change, so I would not expect a different result

itā€™s not a request that goes through the browser.
It goes from katalon directly to the microservice.

Upgrading might be an option down the road, but my company is currently using 6.3.3 across the board.

My bad. I test all my services through the browser and keep forgetting how Katalon WS calls are made.

Wireshark? Fiddler?

this is why I suggested that always to check for response code, before to attempt to parse the json, to avoid code crashes.

Now, to the issue ā€¦ how does the URL of your API request looks like? Does contain special (escaped) characters?
If it is a POST ā€¦ can you show us the body too?
Can you share also the .har file generated by the request?

The URL does not have any special characters,

/api/ws-server/message

It is a POST, it does have escaped characters, and the body looks like below. (it is a constructed message in multiple layers, hence the various escapes)

{
ā€œtopicā€: ā€œ/topic/service/device/messageā€,
ā€œmessageā€: ā€œ{ "devices": [{ "deviceIndicator": "pts", "deviceDuiIndicator": "pts-gui", "deviceProperties":{ "DASSystemConfig": "{ \"name\": \"CPTS TestSystem\" }" }, "status": { "deviceIndicator": "pts", "status": "READY", "statusProperties":{ "DASSystemState": " { \"errorSignal\" : \"OK\", \"doNotLoad\": \"true\" }" }, "level": "READY" } } ], "timestamp": "2019-12-03T14:02:07.971Z", "messageId": "e9265edb-c3e8-42e0-96c9-a826b418cd41", "messageClass": "DALDeviceInfoV1" }ā€
}

Sending this exact message through to the endpoint using the Object Repository results in a 200.
But calling the endpoint from the test using WS returns the 400

WS.sendRequest(findTestObject(ā€˜websocket mock/send messageā€™, [(ā€˜urlā€™) : GlobalVariable.WS_MOCK_URL, (ā€˜messageā€™) : msg]))

I donā€™t have a .har file

carefully check the content of this variable.
the ā€˜nā€™ in the error response may indicate you have somewhere an undesired ā€˜not new line characterā€™ (not properly escaped)

how is this variable produced? it is grabbed by a previous request or created in the script?

LE: to produce reliable Json bodies from the script code, a better approach is to use groovy SimpleTemplateEngine, instead of abusing escapeā€™s (if parametrization is desired)

http://docs.groovy-lang.org/docs/next/html/documentation/template-engines.html

For simple plain bodies, use triple double quoted strings (Gstrings) (also Triple-single-quoted string may work for your case):

see: |Neither double quotes nor single quotes need be escaped in triple-double-quoted strings.|

1 Like

@Ibus

character 110 == ā€˜nā€™ not 10 = \n

1 Like

@Russ_Thomas thx for correction, i amended:

ā€˜not new line characterā€™ 

The content of the message is posted above. It does not vary.
If we had extra escape characters in there, or the json was not properly formatted, would it not fail with both versions?

I agree. It certainly sounds like thereā€™s a parser issue between the two versions. Howeverā€¦

If that were the case, there would have been MANY similar reports from many users. There arenā€™t (werenā€™t) any, to my knowledge.

it may not.
as far as i know there were various updates with regards how the escaping is working (in urlā€™s, in bodies) during various versions ā€¦ so better use proper and easy readable ways to produce your bodies.
will help you to reduce flakiness

As it looks like you have ā€œ and not " in your response. that would not be valid JSON

2 Likes

Where did you see that?

I did Copy and past the json above to http://json.parser.online.fr/ to validate it, and it did say it right away :wink:

Take care with copy and paste from the forum. The forum ALWAYS messes with quotes - itā€™s very annoying.

Using the Crockford original, itā€™s perfectly valid.

@Jens.gr

thatā€™s why I always ask for properly formatted code from the author source.
once pasted as regular text or quote-block, > 50 % of the original code format is destroyed.

and you copy from the forum and paste again somewhere > another source for errors. and so on ā€¦

1 Like

Oh damn, good to know that messes with the sources