ID! validation is returning an error of type string.

[thedodd]

What happened?

When submitting a request where a literal integer is supplied by the client instead of a string literal for the ID! type, the framework's error handling is quite different. The error is presented to the error handler configured by the user, instead of just being flagged as a malformed request and returned as a 400 to the caller automatically.

There appears to be a difference between the type validation of the high-level request object vs the validation of field parameters. This inconsistency complicates error handling, such that it is unclear where in the stack the error is coming from. Perhaps it would be good to use a more identifiable error type so that we can handle it appropriately in the error handler logic.

The question needs to be asked: "is this some unhandled error coming from bad business logic in my code (an ISE), or is this an error which can be presented as-is to the caller?"

What did you expect?

I expected consistency. This is a type validation error. The gqlgen stack should, arguably, be handling this error during the main validation phase and return an error before it ever leaves the gqlgen stack.

Minimal graphql.schema and models to reproduce

type Query {
    getProject(id: ID!): String!
}

Then just query that field with an int instead of a string.

versions

• gqlgen version? v0.9.1
• go version? 1.12.6
• dep or go modules? go modules

[thedodd]

@vektah &| @neelance just wanted to see if either of you have any thoughts on the best way to deal with this. Thanks for all of the work that you've put into this project!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thedodd]

Just adding another heartbeat here (to keep the stale bot reaper from killing this issue).

[cfilby]

@thedodd I had a PR that was related to this, #902 - does that resolve your issue?

[thedodd]

@cfilby that probably will address the issue. Have those changes been released/tagged? I'll test and report back.

[cfilby]

@thedodd it's merged into master but hasn't yet been included in a tagged release. You could test it directly by using the latest master commit instead of a versioned release?

[vvakame]

I close this issue. if its still haven't solved, please mention to me.