`drive.get` hangs when offline and blocks are missing

[josephmturner]

I tested this by attempting to load a file over the network after disconnecting from my wifi AP.

By adding console.log statements, I found that the _open method in the BlobReadStream class, the (this._pos === this.id.byteOffset) is truthy, and then the Hyperblobs.createReadStream hangs here.

[HDegroote]

I think this is expected behaviour, but will let @mafintosh confirm.

You are aware of the existence of the block, so you wait for it until you get it. It will resolve once you do (in your case, when coming back online and connecting to a peer who has that block available).

What would be your expected behaviour? IMO throwing an error when a block can't be immediately fetched, for example due to connectivity issues or because no peer with that block is currently online, is a bad pattern. The general pattern we use is to wait until the block is available

[josephmturner]

@HDegroote Thanks for your response!

As a user, I expect the app to error quickly if I'm disconnected from all other peers and the block is not loaded locally. Somewhere in the stack, I expect a sanity check to throw a useful error like "No peers available - double check your internet connection."

What do you think? Thank you!

[mafintosh]

sounds hard to work with. peers come and go. the above pattern would only work in a centralised system. happy to add to the roadmap to have more options (you can use the timeout btw). for now we have wait & timeout and both allow you to do moth things.

[josephmturner]

Thank you! How about this? ``` let file; if (await drive.entry('/foobar', { timeout })) { file = await drive.get('/foobar') } ``` Getting a file might take a long time depending on the size, but metadata should load quickly if peers are available, so it only uses `timeout` with `await drive.entry()`. Does this approach makes sense? If so, what default timeout would you suggest? The timeout would be configurable.