Remove the clientMutationId requirement by creating a new root id for each executed mutation

[robrichard]

Fixes #1734
Fixes #2333
Fixes #825

Related to relayjs/relay-examples#30
When a mutation is executed, it's payload is added to the store using a key of the serialized arguments. In the Todo Modern example this looks like this:

{
  'client:root:addTodo(input:{"text":"a"})': { ... } // added by mutation response
  'client:VXNlcjptZQ==:__TodoList_todos_connection': {
    edges: [
      __refs: [
        'client:VXNlcjptZQ==:__TodoList_todos_connection:edges:0',
        'client:VXNlcjptZQ==:__TodoList_todos_connection:edges:1',
        'client:root:addTodo(input:{"text":"a"}):todoEdge', // added by mutation imperative updater function
      ]
    ]
  }
}

If you execute a second addTodo mutation with the same arguments, the client:root:addTodo(input:{"text":"a"}) field in the store will get overwritten with the second mutation and the store will look like this:

{
  'client:root:addTodo(input:{"text":"a"})': { ... }
  'client:VXNlcjptZQ==:__TodoList_todos_connection': {
    edges: [
      __refs: [
        'client:VXNlcjptZQ==:__TodoList_todos_connection:edges:0',
        'client:VXNlcjptZQ==:__TodoList_todos_connection:edges:1',
        'client:root:addTodo(input:{"text":"a"}):todoEdge',
        'client:root:addTodo(input:{"text":"a"}):todoEdge',
      ]
    ]
  }
}

When React renders the data, you will have the latter todo in the connection array twice and will likely get an error along the lines of Encountered two children with the same key, <id>. Child keys must be unique; when two children share a key, only the first child will be used.

This was fixed in relay-examples by adding a clientMutationId to the mutation arguments. I don't think this is ideal since

1. it requires the developer to manually add this to each mutation
2. it places an additional constraint on the GraphQL schema to support this field.

The approach I took to fix this, was to use a new root dataID (instead of the static client:root) for results on each mutation. This will namespace results from each mutation so they can never overwrite one another.

With these changes, the relay store now looks like this after completing the same series of mutations:

{
  'client:mutationRoot0:addTodo(input:{"text":"a"})': { ... },
  'client:mutationRoot1:addTodo(input:{"text":"a"})': { ... },
  'client:VXNlcjptZQ==:__TodoList_todos_connection': {
    edges: [
      __refs: [
        'client:VXNlcjptZQ==:__TodoList_todos_connection:edges:0',
        'client:VXNlcjptZQ==:__TodoList_todos_connection:edges:1',
        'client:mutationRoot0:addTodo(input:{"text":"a"}):todoEdge',
        'client:mutationRoot1:addTodo(input:{"text":"a"}):todoEdge'
      ]
    ]
  }
}

I tested this and it works to solve this issue, but I'm unsure if there could be any unintended consequences by this change.

[alloy]

This PR addresses the issue described in #2333. And while this does not remove the ID, it is related to #2077.

[alloy]

@steida Mind testing this PR for your situation? (And is your situation a production app?)

[steida]

@alloy My situation is https://github.com/este/este. Not a production :(

@jstejada What do you think, should I test? Will Relay team merge it? Thank you.

[steida]

@kassens What do you think? Should I test it? Is there any chance it will be merged in, say, next six months?

[alloy]

@steida We should help the Relay team by testing them preemptively so that when they have time they will know it was already tested by at least somebody.

[taion]

Is there a constructive reason for the old behavior, incidentally? It does seem odd to essentially assume idempotency for all mutations.

[facebook-github-bot]

@jstejada has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[dblock]

@AndrewIngram mentions in https://graphql.slack.com/archives/C0BEXJLKG/p1531176878000009 that another work-around until this is merged is to clone the data that comes back. Anyone has such code to share here that, hopefully, avoids the long boilerplate in https://facebook.github.io/relay/docs/en/mutations.html#updater-configs?

[taion]

BTW, the same problem arises for subscriptions. In this case the fix needs to be applied in this manner, as there's no place to inject a payload sequence ID (as far as I'm aware).

That said, @AndrewIngram's workaround is pretty satisfactory in practice.

[sibelius]

@jstejada @kassens can we try to import this again ?

we could also merge this one #2401 when this has landed

[jstejada]

thanks for the ping @sibelius! apologies again for the delay in getting to this. We still need to discuss internally a little bit what the best approach would be here. From a short discussion, it seems like we could address separately the problem of ensuring that we don't overwrite mutation payloads vs removing the requirement for a clientMutationID. cc @josephsavona @kassens

[taion]

I just ran into something like this. We've switched our mutations to return unions between the payload type and various typed errors as their root types. When running a mutation with the same inputs leads to a different concrete return type (e.g. an error instead of a payload), we get an invalid record update due to the type mismatch, because the root field gets reused.

[tlvenn]

@jstejada do you have any update on this particular issue ? Thanks in advance.

[jstejada]

i think @tyao1 already fixed this

[robrichard]

@jstejada @tyao1 I'm pretty sure this is still an issue. I just tested in relay-examples todo with relay v7 and was able to reproduce

[kassens]

This has been a long time coming, thanks @robrichard for the initial PR and @tyao1 for picking this back up!

[facebook-github-bot]

@tyao1 merged this pull request in c988815.

[ersinakinci]

Can someone please comment with respect to the relevance of this PR to the following, taken from the "GraphQL Server Specification" section of the documentation?

Relay uses a common pattern for mutations, where there are root fields on the mutation type with a single argument, input, and where the input and output both contain a client mutation identifier used to reconcile requests and responses.

Is it correct to say that this documentation is incorrect because client mutation identifiers no longer exist? Or do they exist but they're an internal API (e.g., auto-generated)? Or something else...?

[sibelius]

It is still a common pattern, but not a requirement anymore

[pvgoddijn]

any guidance on how to implement the mutation identifier when writing a compatible server?

[taion]

If you're using JS, graphql-relay provides primitives for this. Otherwise, many other frameworks have their own equivalents. It just depends on which server you're using.

[sibelius]

clientMutationId is like an idempotence key (https://stripe.com/docs/api/idempotent_requests)

so your server can validate that user hasn't sent the same mutation twice

[taion]

not exactly – it was originally meant for clients to be able to correlate mutation payloads with mutations, without assuming request/response semantics on the network transport