Error updating schema with @custom directive

[forstmeier (John Forstmeier)]

Hi!

I’m running into this error when I try to update the schema:

{"errors":[{"message":"resolving updateGQLSchema failed because input:1: Unexpected \u003cInvalid\u003e\n (Locations: [{Line: 3, Column: 4}])","extensions":{"code":"Error"}}]}

Here is a link to the current schema. What I don’t understand is that after adding in the @custom directive mutations at the bottom, I am now having issues uploading the schema. I may have made some other change but I’ve primarily been focusing on trying to get these to work. Any guidance on deciphering this error would be great!

Best,
John

[amaster507 (Anthony Master)]

Ugh, @core-devs is there anyway to make these error messages more friendly? Being native to MySQL, their error messages are easier to digest at least having a snippet of the query where the problem lies. Maybe instead of “Line 3, Column: 4” You could provide the snippet of schema. This will usually point to the error faster. Most times it is an extra space, colon, unmatching brackets, etc.

@forstmeier, can you provide schema? I understand that is not always possible. I try to keep a working version of my schema in our github so we at least have something to compare against with what changed. Do you have anything like this to know exactly what you changed? If so, can you post at least those parts?

[forstmeier (John Forstmeier)]

Hey, @amaster507! Here’s the link to the current schema on the branch I’m currently working on: https://github.com/forstmeier/backend/blob/reduce-footprint/database/schema.graphql. I can look at it more closely but the history for the schema.graphql file over the past 10-ish days seems relatively innocuous.

[amaster507 (Anthony Master)]

Slash has a little better error handling:

resolving updateGQLSchema failed because input:601: Type Mutation; Field editUser; body template inside @custom directive could not be parsed.
input:607: Type Mutation; Field removeUser; body template inside @custom directive could not be parsed.

This is interesting. Not sure why it would allow your createUser to go through seemingly without error, but error parsing your editUser and removeUser.

This was a long shot, but I actually resolved out why. Not that I think it is correct, but that it is a Dgraph bug/restriction.

Your body for editUser and removeUser both contain this snippet:

auth0ID: $auth0ID

I was able to receive a successful parse by using instead:

authID: $auth0ID

I believe that numbers are allowable in property names in JSON.

The problem was identified here:

@custom mutation: underscores within POST body

Thanks, This is a limitation currently. At present, only [a-zA-Z] is supported as the character set for keys in body. We should expand it to accept general things like underscores, hyphens or basically any character that one may use in json keys.

But was should now be resolved as also noted on that same thread:

@custom mutation: underscores within POST body

Hey @miko, This has been added in master with this PR. Note that now the character set for keys in body is /[_A-Za-z][_0-9A-Za-z]*/ which is same as the character set for names in GraphQL spec. Closing this topic. Thanks

It was committed here:

https://github.com/dgraph-io/dgraph/commit/02820c8921a3a954880505c18cc5f0c875168b9a

And can be seen inside version 20.07.1-rc1 here:

Commits · dgraph-io/dgraph

Which version are you running?

[forstmeier (John Forstmeier)]

Awesome, thank you! That was exactly the issue.

I’m running the master branch (haven’t pulled down the most recent stuff in a week or so) for reference.

[pawan (Pawan Rawal)]

Seems like the error message was coming from an older version hence wasn’t clear enough. This is confirmed by

@amaster507

Slash has a little better error handling:

Note Slash has parity with the 20.07.1-rc.