search

ipfs / go-graphsync

Initial Implementation Of GraphSync Wire Protocol
Other
100 stars 38 forks source link

graphsync client should handle missing blocks on responder side #180

Closed raulk closed 3 years ago

raulk commented 3 years ago

Many legit use cases rely on sparse DAGs, understood as DAGs containing blocks not present in the responder's blockstore. Examples include federated/decentralised DAGs, blockchains nodes with limited history lookbacks, DAGs spanning many Filecoin deals, etc.

Right now, go-graphsync FUBARs with: Remote Peer Is Missing Block when the responder indicates that a block is missing, which makes use cases like that impossible.

@hannahhoward indicates:

Graphsync returns error channel that can send multiple errors. When you get a missing block, it sends an error on the error channel but the traversal continues. The assumption was the consuming code would be reading the error channel and would decide whether to terminate or continue. So yes there’s a way. I think the error should be singular, and we should put the missing block as extra information in the response channel. I’m definitely open to that redesign — it’s a breaking change of course.

raulk commented 3 years ago

The "breaking change" aspect can be handled by providing a requestor option: ContinueOnMissingBlock, or something like that.

hannahhoward commented 3 years ago

superseded by https://github.com/filecoin-project/lotus/issues/7227, required functionality lives outside go-graphsync