Skip to content

Scalars within input objects cannot be parsed in MethodFieldResolver #466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
oryan-block opened this issue Dec 22, 2020 · 4 comments
Closed
Assignees
Labels

Comments

@oryan-block
Copy link
Collaborator

Description

As described in graphql-java-kickstart/graphql-spring-boot#404 scalars work fine by themselves (or as an array) but not if they are defined as a field on an input object.
This is because for input objects shouldValueBeConverted is false and we try to use the object mapper to parse them.
If the mapper doesn't know how to parse that scalar, and there's no reason it should, it will fail (this can be worked around by providing a deserializer with the mapper through the objectMapperProvider option but probably not the solution we're looking for).

Expected behavior

Both queries should work:

type Query {
    test1(input: Upload): ID!
    test2(input: FileInput): ID!
}

scalar Upload

input FileInput {
    name: String!
    file: Upload
}

Actual behavior

Second query fails with:

java.lang.IllegalArgumentException: Cannot construct instance of `javax.servlet.http.Part` (no Creators, like default construct, exist): abstract types either need to be mapped to concrete types, have custom deserializer, or contain additional type information
 at [Source: UNKNOWN; line: -1, column: -1] (through reference chain: graphql.kickstart.tools.FileInput["part"])

Steps to reproduce the bug

  1. run query test2
@oryan-block
Copy link
Collaborator Author

I've proposed two possible workarounds for this issue:
https://gist.github.com/oryan-block/7630eb6d352778164c7fbdbb45e24265
One of which is the aforementioned deserializer idea.

@PhilippS93
Copy link

@oryan-block, do you know, when the proposed workaround will be merged into to library?

@oryan-block
Copy link
Collaborator Author

@PhilippS93 the workaround doesn't require changes to the library. It's all on the client side.

@oryan-block
Copy link
Collaborator Author

Added this to the known issues page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants