Parallel Update operations on the same item reports misleading responses

[severussundar]

When two update mutations act on the same item, the responses returned back to these mutations are misleading.

Update Mutation that was run:

mutation updateNotebook($id: Int!, $item: UpdateNotebookInput!) {
        updateNotebook(id: $id, item: $item) {
          id
          color
        }
      }

When two graphQL mutations were executed in parallel with the following variables,

{
    "id": 3,
    "item": {
      "color": "cyan"
     }
  }

{
   "id": 3,
   "item": {
      "color": "magenta"
    }
}

the responses for both the mutations were either

{"data":{"updateNotebook":{"id":3,"color":"magenta"}}}

or

{"data":{"updateNotebook":{"id":3,"color":"cyan"}}}

When an update mutation is performed to update the color to cyan, returning a response with the color as magenta is not ideal.

This behavior is observed with transaction isolation levels: READ COMMITTED and SERIALIZABLE .

The response for each mutation should ideally be the result of that particular update operation.

Correct responses:

1. updateMutation with variable color as cyan : {"data":{"updateNotebook":{"id":3,"color":"cyan"}}}
2. updateMutation with variable color as magenta : {"data":{"updateNotebook":{"id":3,"color":"magenta"}}}

Possible Root Cause:
When executing the mutations, the mutation is first performed and then the required columns are read from the updated item to construct the response for the graphQL request. The update and the read operations might not be happening in a single transaction.

Related issue: #138 . The core idea or concept for both these issues are the same and there could be an overlap in approaches.

[Aniruddh25]

Moving to Nov2022 since #885 has higher priority.

[Aniruddh25]

Nested Mutations is of higher priority than this issue which tracks performing mutations in a transaction. So moving to Jan2023