ipfs refs times out

[jbenet]

ipfs refs -r <ref> sometimes times out for me, and returns a 0 error code!!! it should return an error code...

[whyrusleeping]

does it time out for blocks that you know are available somewhere?

[jbenet]

Yes.

—
Sent from Mailbox

On Sat, Apr 11, 2015 at 12:02 PM, Jeromy Johnson notifications@github.com
wrote:

does it time out for blocks that you know are available somewhere?

Reply to this email directly or view it on GitHub:
#1050 (comment)

[cryptix]

I looked into this twice and honestly, I couldn't make heads or tails of it. There is really now structured way of handling contexts right now and you can still find context.TODO() in some places, I think.

The problem I had tracking this down betters is, that we are passing up errors plainly without wrapping them. I.e.

_, err := coreStuff.It(...)
if err != nil {
  return err
}

// instead of 
_, err := coreStuff.It(...)
if err != nil {
  return errgo.Wrap(err, "we failed to Stuff.It ")
}

Without this, the timeout cancelations end up as plain context: deadline exceeded at the receiving end of the commands lib leaving you without a trace about which step in the command actually timed out.

I had good experiences with errgo, like that from juju or gopkg.in to make errors more expressive. With some discussion of corse, I'd like to start introducing it in the next sprint. Having a general pattern for error handing would help us in general I think. This is still alpha software after all and proper error traces would also help us with big reports from users.

[whyrusleeping]

most likely, something is happening that just causes the channel of keys to be closed prematurely. we need a way of signalling that a channelmarshaler has failed.

[whyrusleeping]

this has been addressed