-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Retrieval is not idempotent #6228
Comments
Here is another example of the same thing where client keeps paying for data even though the full size of the CID has already been retrieved (CID is 1 GiB exactly). Again, this is a repeat retrieval where the client should have already had the blocks of this CID in its store from a previous attempt. Seems like that might be where the bug is cropping up.
Here's what
My theory is that there is some bug where when the client already has all the blocks in its block store, it winds up in a loop where it keeps paying more money to the provider even though the transfer is already finished. |
cc @dirkmc |
I believe this should be resolved by this PR: #6149 |
@dirkmc I built from PR #6149 this morning and re-tested the 816.1 MiB CID discussed in the issue description. I'm still seeing it fail, although the way it fails is different now. Here's the exact command and output:
I did a 2nd attempt, but I got identical output. EDIT: This problem opened as new issue #6297 |
Describe the bug
tldr A retrieval can't get past 816.1 MiB, despite repeated attempts. Provider is responsive. Client can complete other retrievals. Client keeps paying more FIL for no additional data. EDIT: I think this bug happens when the client already has some or all of the blocks from a previous failed/aborted retrieval. Explained below.
I ran this command
lotus client retrieve --miner f019002 bafykbzacea6lb336ja5htts4c2cetbl5qeswllzfl72ynvcya65jpluhqxgpg /dev/null
. The retrieval was working correctly for a while, but then froze at 816.1 MiB. It stayed in this state of ~15 minutes:I used
cancel-transfer
to kill the retrieval and re-started it with the same command as above. The retrieval again worked until it reached 816.1 MiB. Then the client went into a loop where it continued to send funds, but received no data in return:Version (run
lotus version
):To Reproduce
Commands show above.
Expected behavior
The transfer should continue to the full size of the payload cid (size not known to me) and then complete successfully. The client should not keep paying more FIL for no additional data.
The text was updated successfully, but these errors were encountered: