Comment 5 for bug 718924

There's a further problem here.

First, a PutContent(hashA->hashB) is queued, then a second one, PuContent(hashA->hashC).

The second one tries to blindly cancel the first one. If the cancellation is real, all is ok. But this bug is about what happens if the command just finished before the cancel.

The real issue is that if the first command got into the server before cancellation, the hash in the server will be hashB, and second command will fail, generating a conflict. If the second command nows that the first one was really cancelled or not is irrelevant, really.

So, the solution is:

- The second command tries to cancel the first one. It will tell if it was really cancelled or not.

- The second command *always* get the previous hash from FSM just before running, will not have it when the Upload is created.