Skip to content
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

2.0 Bug: Mutations return the field type if output not supplied #585

Closed
BossGrand opened this issue Oct 30, 2017 · 4 comments
Closed

2.0 Bug: Mutations return the field type if output not supplied #585

BossGrand opened this issue Oct 30, 2017 · 4 comments

Comments

@BossGrand
Copy link
Member

BossGrand commented Oct 30, 2017

You can reproduce by creating a simple mutation

import graphene

class TestMutation(grapheneMutation):
    test = graphene.String()

    @classmethod
    def mutate(cls, root, info, **kwargs):
        return TestMutation()

When this mutation is ran the return for test will be

mutation{
    testMutation{
         test
    }
}

"test": "<graphene.types.scalars.String object at 0x108617a20>"

took me a while to figure out what was happening, I'll keep digging see if I can find the root cause. Anyone else running into this issue?

@BossGrand BossGrand changed the title Bug: Mutations return the field type for output if not supplied 2.0Bug: Mutations return the field type for output if not supplied Oct 30, 2017
@BossGrand BossGrand changed the title 2.0Bug: Mutations return the field type for output if not supplied 2.0 Bug: Mutations return the field type for output if not supplied Oct 30, 2017
@BossGrand BossGrand changed the title 2.0 Bug: Mutations return the field type for output if not supplied 2.0 Bug: Mutations return the field type if output not supplied Oct 30, 2017
@jlward
Copy link

jlward commented Oct 31, 2017

I found this as well.

I was able to "fix" it by making my mutation explicitly set None for each field not being assigned. This fixed a possibly related bug where I was getting errors in the response for custom types and other scalars.

import graphene

class TestMutation(grapheneMutation):
    test = graphene.Int()

    @classmethod
    def mutate(cls, root, info, **kwargs):
        return TestMutation()
mutation{
    testMutation{
         test
    }
}

'errors': [{'message': "int() argument must be a string or a number, not 'Int'"}]

Funny thing is the rest of the response had the correct data (in my case). I think graphene.String accidentally doesn't produce an error because you can call str() on almost anything without it causing an exception.

Hope this helps, and if you would rather I make an independent issue I'd be happy to.

TLDR: Default values are no longer None. So explicitly pass along None for old behavior.

@BossGrand
Copy link
Member Author

Yea thats what I ended up doing to. I have a subclass of mutation that I use on all my mutations so it was relatively painless.

I think that long term this needs to be fixed in the code base

@jlward
Copy link

jlward commented Nov 1, 2017

def test():
    class CreateBlank(Mutation):

        class Arguments:
            name = String()

        string = String()
        integer = Int()

        def mutate(self, info, **args):
            return CreateBlank()

    class Query(ObjectType):
        a = String()

    class MyMutation(ObjectType):
        create_blank = CreateBlank.Field()

    schema = Schema(query=Query, mutation=MyMutation)
    result = schema.execute(''' mutation mymutation {
        createBlank(name:"Peter") {
            string
            integer
        }
    }
    ''')
    assert not result.errors
    assert result.data == {
        'createUser': {
            'string': None,
            'integer': None,
        }
    }

I had some trouble figuring out where the problem is happening at. But I was able to create a test that illustrates the issue here. It's not a PR, but since I haven't found where to actually fix it, I'd rather get the test out there. Hopefully it can help someone who actually knows what they are doing fix the problem.

@syrusakbary
Copy link
Member

Just fixed this in master. The issue was happening on both ObjectTypes and Mutations (when used as containers)

I also added tests so this issue is not repeated in the future :)

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

No branches or pull requests

3 participants