The order of the definition of an relation input has unexpected side effects

[megawubs]

Describe the bug
When I want to both sync existing relations and create a new relation on a BelongsToMany or MorphsToMany relationship, the order of the fields in the input type influences if the relation is actually stored or not. For example, if create comes before sync in the input type, the relation is created but sync is executed after the create, thus removing the relation with the newly created one. Once the sync key is moved before the create key, the sync happens before the create, thus making sure all relations are still set.

Expected behavior
When syncing and creating both in one mutation, the created entity should be linked, not only the synced. There should not be a dependancy on the order of the fields in the schema to get this to work.

Schema
This input does sync and store, but does not keep the relation of the stored tag

input UpdateTagRelation {
  create: [StoreTag!]
  connect: [Int!]
  sync: [Int!]
  disconnect: [Int!]
}

This input does sync and store, and keeps the relation of the stored tag.

input UpdateTagRelation {
  sync: [Int!]
  create: [StoreTag!]
  connect: [Int!]
  disconnect: [Int!]
}

Environment

Lighthouse Version: dev-master
Laravel Version: 5.8
PHP Version: 7.2

[spawnia]

I opened on issue with the GraphQL spec to hopefully clarify the semantics about the ordering of arguments within the schema definition. graphql/graphql-spec#577

In the particular example you outlined, i guess it makes sense to apply the operations in the order you proposed.

I am not quite sure we should decide in advance in what order they should be applied though, ignoring the schema definition. It might be valuable to allow the schema definition to influence the order of execution explicitely, as use cases may differ - especially when we consider other relationship types.

[spawnia]

As the discussion in graphql/graphql-spec#577 indicates, i think we should not rely on the order of argument definition as defined in the schema.

So yeah, let's define a fixed order in which the nested operations are handled.