many_to_one_extras not correctly saving reverse relations

[calummackervoy]

Expected Behaviour:

The following example is given in the documentation, for nested fields usingmany_to_one_extras:

class CreateUserMutation(DjangoCreateMutation):
    class Meta:
        model = User
        many_to_one_extras = {
            "cats": {
                "add": {"type": "auto"}
            }
        }

When running the following query, I expect Cats to be saved, and to have the owner of the freshly created user object

Current Behaviour:

I have Parent and Child models, where one Parent can have many children

For those models I've created the following types:

# Parent
class CreateParentMutation(DjangoCreateMutation):
    class Meta:
        model = Parent
        ...
        many_to_one_extras = {
            "children": {
                "add": {
                    "type": "CreateChildMutationInput",
                },
            }
        }

# Child
class CreateChildMutation(DjangoCreateMutation):
    class Meta:
        model = Child

This to me seems to be the same as the example. When running a query passing:

mutation createParent($input: CreateParentMutationInput!){
                createParent(input: $input) {
                    parent {
                        id
                        children {
                            id
                        }
                    }
                }
            }

I get the following error:

AssertionError: 'errors' unexpectedly found in ['errors', 'data'] : {'errors': [{'message': 'NOT NULL constraint failed: children_child.parent_id', 'locations': [{'line': 3, 'column': 17}], 'path': ['createParent']}], 'data': {'createParent': None}}

Which suggests that the reverse relation of child.parent hasn't been saved? I can't pass the parent's id into the children of the query obviously because it doesn't yet exist

I thought this might be related to https://github.com/tOgg1/graphene-django-cud/issues/17 but I thought that it doesn't match the behaviour in the documentation, so maybe it's a bug