after having upgraded Dgraph to v24.0.0, I have a problem with mutating predicates of nodes that are already present in the database if the latter was restored from a backup. To isolate the problem, I have set up a sample database along the lines of the example in the docs. The schema is
name: string @index(term) . type Person { name }
I have generated a single node via
set { _:a <dgraph.type> "Person" . _:a <name> "A B" . }
Then, I have created a backup, set up a new Dgraph instance, and restored the backup in that instance. After querying the node’s uid (yielding 0x3 say), I have tried to change its name to “B C” via
set { <0x3> <name> "B C" . }
but this resulted in an error
[mutation.go:145] verifyUid returned error: Uid: [3] cannot be greater than lease: [0].
Seemingly, the system thinks I want to create a new node rather than change a statement about an existing node. In the original instance from which the backup has been created, the mutation works fine. In versions < 24 I never had such an issue.
lease: [0] indicates that your zero instance is not aware of any nodes created by alpha. This is the case if you use an empty zero instance, instead of the one used during the restore process.
You can try to use the /assign endpoint of your zero instance to fix the lease issue (More about Dgraph Zero - Deploy). This should not be necessary during a normal restore process.
I am not sure you require to use restore like this fro upgrading. Specially to 24.0.0. If you are upgrading from 23.x.y to 24.0.0, you can just replace the binary. No steps required.
As @vnium said, You can just call /assign?what=uids&num= to fix your issue right now.
Sorry, I was not clear about that. Generation and restoration of the backup has all been done in 24.0.0. I just mentioned upgrading because the issue did not show up in former versions. However, as vnium has pointed out, it had nothing to do with versions, but was a failure in the restoration process. Thank you.