Execution order in multi query and multi mutation upsert

I have a schema like this

type A {
	a.id:			int
}

type B {
	b.id:  	  int 
	b.children: [uid]
}
b.id:      		int @index(int) .
a.id:			int @index(int) .
b.children:       [uid] @reverse .

I need to perform an operation where I need to delete the children from B(0x68768) which matches the children of B(0x68769) by a.id, and then copy children from B(uid1) to B(uid2).

Example

This data

{
  "data": {
    "B": [
      {
        "uid": "0x68768",
        "A": [
          {
            "uid": "0x6876a",
            "a.id": 1
          },
          {
            "uid": "0x6876b",
            "a.id": 2
          }
        ]
      },
      {
        "uid": "0x68769",
        "A": [
          {
            "uid": "0x68767",
            "a.id": 1
          }
        ]
      }
    ]
  },

after the operation should change to

{
  "data": {
    "B": [
      {
        "uid": "0x68768",
        "A": [
          {
            "uid": "0x68767",
            "a.id": 1
          },
          {
            "uid": "0x6876b",
            "a.id": 2
          }
        ]
      },
      {
        "uid": "0x68769",
        "A": [
          {
            "uid": "0x68767",
            "a.id": 1
          }
        ]
      }
    ]
  },

This is my upsert query which seems to work fine.

upsert {
  query {
    toAdd(func: has(a.id)) @filter(uid_in(~b.children, "0x68769")) {
          pUid as uid
          pId  as a.id
    }     
    toDel(func: eq(a.id, val(pId))) @filter(uid_in(~b.children, "0x68768")) {
	dUid as uid
    }
  } 
    
  mutation @if(gt(len(pUid), 0)) {
  set  {
      <0x68768> <b.children> uid(pUid) .
	  }
  }
    
  mutation @if(gt(len(dUid), 0)) {
  delete  {
      <0x68768> <b.children> uid(dUid) .
	 }
  }
}

But I need to understand if this is deterministic or not?
This query will work fine if all the queries are evaluated before all execution of any mutations.
But if the order of execution is changed to ‘toAdd’ → set mutation → toDel → delete mutation. It will give wrong result because eq(a.id, val(pId)) will match both 0x68767 and 0x6876a instead of just 0x6876a.

As far as I know, the order is irrelevant. There are no cases of Upsert (or Bulk upsert) with mutation and Delete operations at the same time having problems. I don’t have a technical answer right now, if you can wait I can ask an engineer (it can take considerable time).

Anyway, If you find any issue, please report as a bug.

Cheers.

Well, as I have mentioned in the example, the order of execution is relevant here. One of the mutations affects the result of one of the queries which in turn affects the result of another mutation.

So if internal implementation of the execution is based on graph formed by variables and their dependency in the upsert block, and if independent mutations/queries can be performed in any order then final result will vary in this case.