renter failed when needing to use the cached revision during upload
Created by: david60
Hi,
I saw my renter and a host go through this sequence:
While uploading, the renter sends data and revision number X to host. Host accepts; but sends WriteNegotiationStop, and then the transactions signatures. (Stop because I think it had reached its time limit for revision iterations).
Renter treats the stop as an error and considers this revision failed. So at this point it has revision X-1 in the contact, and revision X in the cachedRevisions. It attempts to connect to the host again, using revision X-1, but fails with revision mismatch. It then uses the cached revision, and connects and sends revision X+1. The host rejects this because the file merkle root is bad. The host's storageobligation is still at revision X. But the renter[correction] has revision X-1 persisted in the contract and now only has revision X+1 in the cached revisions. So it is not able to successfully connect to the host again to revise the contract any more.
It seems a problem may be that when the cached revision is applied, the contract's MerkleRoots list is then inconsistent with the revision that it got from the revision cache.
A separate issue might be the handling of the "stop" from host to renter during the revision iteration.