You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the retrieval unseal price is > 0, the sequence should be:
Client opens channel to provider
Provider requests unseal payment
Client sends unseal payment
If Provider dosen't have an unsealed copy lying around, it unseals the Sector. If it has an unsealed copy lying around, this step is a no-op.
Provider stores unsealed data in blockstore
Provider sends blocks to client
However there is a bug whereby currently the provider starts trying to send blocks as soon as it receives the unseal payment. It does not wait until the unsealed data has been read into the blockstore. The result is that graphsync fails to read the expected blocks from the blockstore and the deal fails.
Proposed solution
The ProviderRevalidator should return ErrPause from Revalidate() if the unsealed deal data hasn't been read into the blockstore.
The text was updated successfully, but these errors were encountered:
But why does it want unseal payment when the deal is fast-retrieval (already unsealed)? Is that how it supposed to work, always unseal regardless it's fast-retrieval or not?
This issue is likely the root cause of filecoin-project/lotus#5829 and filecoin-project/lotus#5530
Background
When the retrieval unseal price is > 0, the sequence should be:
However there is a bug whereby currently the provider starts trying to send blocks as soon as it receives the unseal payment. It does not wait until the unsealed data has been read into the blockstore. The result is that graphsync fails to read the expected blocks from the blockstore and the deal fails.
Proposed solution
The ProviderRevalidator should return ErrPause from Revalidate() if the unsealed deal data hasn't been read into the blockstore.
The text was updated successfully, but these errors were encountered: