dgraph-js: Json parse error

Version: 1.0.2 (also applies to 1.0.3) Dgraph version: 1.0.2

After running a query of the form via txn.query(…):

{
    classes(func: eq(<${sp.VertexType}>, "Class"), orderasc: ${sp.Name}) {
      uid: _uid_
      name: ${sp.Name}
      ...
}

Within your method Response.getJson(), the call to super.getJson() returns a string that is not valid Json:

"classes": [{"name":....

This results in a JSON parse error, “Unexpected token : in JSON at position 9”

Was there a recent change that would have changed the format of the string returned from super.getJson() so that it is missing an opening brace?

EDIT: the value returned from super.getJson() is determined to be Uint8 and gets put through the u8ToStr function.

EDIT 2: I have found that the last character returned from super.getJson() is ASCII character #26 (“SUBSTITUTE”). When I append a brace to the front of the result, and remove this “SUBSTITUTE” from the end, the string is valid JSON. So it looks like the query result may be incorrectly offset by 1 character.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 21 (6 by maintainers)

Most upvoted comments

@roscioli yes definitely - what I found is that when the leading ‘{’ is missing, the trailing character is ASCII character ID 26, “substitute”. That character also broke the parse - so whenever I append the ‘{’, I also have to remove the last character.

I’ve put this patch code in the library. I’m going to add some code to write the failed request / responses to the filesystem for repro purposes, but I haven’t done it yet.

if(!jsonStr.startsWith('{')) {
	console.error('FYI - in patched code.  charcode at beginning: ' + jsonStr.charCodeAt(0) + ' and end: ' + jsonStr.charCodeAt(jsonStr.length - 1))
	jsonStr = ('{' + jsonStr)
	jsonStr = jsonStr.substr(0, jsonStr.length - 1)
}

@roscioli , I’m getting it again too, but I haven’t bothered to re-open the issue until I can produce a solid repro. I’ll re-open now though since you’re also getting the issue.

Have you noticed a pattern with the volume of data you’re returning in the queries that fail? The only pattern I’ve noticed so far is that the failures happen when the response payloads are large.