Closed rvagg closed 2 years ago
Already seeing some unconfirmed in my local instance on this branch.
Base: 13.98% // Head: 13.92% // Decreases project coverage by -0.05%
:warning:
Coverage data is based on head (
da797f2
) compared to base (fa63208
). Patch coverage: 14.28% of modified lines in pull request are covered.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Upon successful retrieval, provide a confirmation along with the reported event that the retrieval resulted in the block being stored in the blockstore. Using
retrievedCids
as a proxy isn't enough because it's possible (with some non-trivial probability) that a retrieval takes place for a block that's just been retrieved as part of a parallel retrieval, so graphsync doesn't need to transfer any blocks.The backstory for this is that we're seeing evidence of cases where a retrieval might look successful but doesn't result in any blocks being transferred that can't be explained by the block having already been in the blockstore. So now we get a
retrievedCids
int and aconfirmed
bool on the events. When we see aconfirmed
offalse
for a"success"
event then it's a bug. The intended behaviour of the stack is that"success"
is always confirmed.