Our client library has a simple retry implementation, intended to catch one-off transient errors that might happen in production. This is useful, for example, in cron jobs that loop over a large number of requests -- if a single transient error does occur, the client can issue a retry to avoid the developer using the library from having to handle those exceptions.
Previously, we removed that retry logic for mutation-based queries, as it's possible the transient error occurred after the mutation successfully executed, and double-running a mutation could put the data into an inconsistent state. However, sometimes a developer knows that the mutation is safe to replay.
Solution
Very simply: allow the developer to say, "it's okay to replay mutation" via a boolean flag.
Background
Our client library has a simple retry implementation, intended to catch one-off transient errors that might happen in production. This is useful, for example, in cron jobs that loop over a large number of requests -- if a single transient error does occur, the client can issue a retry to avoid the developer using the library from having to handle those exceptions.
Previously, we removed that retry logic for mutation-based queries, as it's possible the transient error occurred after the mutation successfully executed, and double-running a mutation could put the data into an inconsistent state. However, sometimes a developer knows that the mutation is safe to replay.
Solution
Very simply: allow the developer to say, "it's okay to replay mutation" via a boolean flag.