Cannot add link to object

[thiagodelgado111]

After upgrading from ipfs-api v3.0.0 to v12.1.7, I'm having a problem to use object.patch.addLink (I couldn't find an example on how to use it so maybe I'm doing it wrong).

Expected behaviour

ipfs.object.patch.addLink('QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn', {
  name: 'QmaKhL4gTv1B5CHy963L9G6dp8Yqqx66TUUSDrihxAcLvL',
  multihash: 'QmaKhL4gTv1B5CHy963L9G6dp8Yqqx66TUUSDrihxAcLvL',
  size: 95
})

My assumption is that it would return me a promise than when resolved would give me an object with a new hash.

Current behaviour

When I call the addLink as above, I get an error from ipfs-api (and from go-ipfs daemon).

>> error on add link:  { [Error: invalid 'ipfs ref' path] code: 0 }
>> 15:47:15.889 ERROR commands/h: a panic has occurred in the commands handler! handler.go:127
>> 15:47:15.889 ERROR commands/h: runtime error: index out of range handler.go:128
>> goroutine 2058135 [running]:
>> runtime/debug.Stack(0x21, 0xc4202b94b0, 0x260087)
>> 	/home/whyrusleeping/go/src/runtime/debug/stack.go:24 +0x79
>> runtime/debug.PrintStack()
>> 	/home/whyrusleeping/go/src/runtime/debug/stack.go:16 +0x22
>> github.com/ipfs/go-ipfs/commands/http.internalHandler.ServeHTTP.func1()
>> 	/builds/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/commands/http/handler.go:130 +0x160
>> panic(0x8123e0, 0xc4200120c0)
>> 	/home/whyrusleeping/go/src/runtime/panic.go:458 +0x243
>> github.com/ipfs/go-ipfs/core/commands.glob..func70(0xd63820, 0xc420ff8fc0, 0xd62c00, 0xc420c4e150)
>> 	/builds/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/core/commands/publish.go:82 +0x856
>> github.com/ipfs/go-ipfs/commands.(*Command).Call(0xe20380, 0xd63820, 0xc420ff8fc0, 0x0, 0x0)
>> 	/builds/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/commands/command.go:116 +0x286
>> github.com/ipfs/go-ipfs/commands/http.internalHandler.ServeHTTP(0x0, 0xc4200c6e20, 0x1a, 0xc420b8d320, 0xc42033e1e0, 0x98ad28, 0xc42015a180, 0xc4201ae130, 0xe20380, 0xc420b8d230, ...)
>> 	/builds/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/commands/http/handler.go:186 +0x3d2
>> github.com/ipfs/go-ipfs/commands/http.(*internalHandler).ServeHTTP(0xc42077c960, 0xd59640, 0xc42002a218, 0xc420730b40)
>> 	<autogenerated>:4 +0x8a
>> gx/ipfs/QmQzTLDsi3a37CJyMDBXnjiHKQpth3AGS1yqwU57FfLwfG/cors.(*Cors).Handler.func1(0xd59640, 0xc42002a218, 0xc420730b40)
>> 	/builds/distributions/dists/go-ipfs/gopath/src/gx/ipfs/QmQzTLDsi3a37CJyMDBXnjiHKQpth3AGS1yqwU57FfLwfG/cors/cors.go:188 +0xe9
>> net/http.HandlerFunc.ServeHTTP(0xc420282da0, 0xd59640, 0xc42002a218, 0xc420730b40)
>> 	/home/whyrusleeping/go/src/net/http/server.go:1726 +0x44
>> github.com/ipfs/go-ipfs/commands/http.Handler.ServeHTTP(0x0, 0xc4200c6e20, 0x1a, 0xc420b8d320, 0xc42033e1e0, 0x98ad28, 0x0, 0xc4201ae130, 0xe20380, 0xc420b8d230, ...)
>> 	/builds/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/commands/http/handler.go:119 +0x5e
>> github.com/ipfs/go-ipfs/commands/http.(*Handler).ServeHTTP(0xc420122ae0, 0xd59640, 0xc42002a218, 0xc420730b40)
>> 	<autogenerated>:5 +0x96
>> net/http.(*ServeMux).ServeHTTP(0xc420350060, 0xd59640, 0xc42002a218, 0xc420730b40)
>> 	/home/whyrusleeping/go/src/net/http/server.go:2022 +0x7f
>> net/http.(Handler).ServeHTTP-fm(0xd59640, 0xc42002a218, 0xc420730b40)
>> 	/home/whyrusleeping/go/src/net/http/h2_bundle.go:4084 +0x4d
>> gx/ipfs/QmR3KwhXCRLTNZB59vELb2HhEWrGy9nuychepxFtj3wWYa/client_golang/prometheus.InstrumentHandlerFuncWithOpts.func1(0xd5a700, 0xc42027e820, 0xc420730b40)
>> 	/builds/distributions/dists/go-ipfs/gopath/src/gx/ipfs/QmR3KwhXCRLTNZB59vELb2HhEWrGy9nuychepxFtj3wWYa/client_golang/prometheus/http.go:287 +0x2ab
>> net/http.HandlerFunc.ServeHTTP(0xc42077c910, 0xd5a700, 0xc42027e820, 0xc420730b40)
>> 	/home/whyrusleeping/go/src/net/http/server.go:1726 +0x44
>> net/http.(*ServeMux).ServeHTTP(0xc420350000, 0xd5a700, 0xc42027e820, 0xc420730b40)
>> 	/home/whyrusleeping/go/src/net/http/server.go:2022 +0x7f
>> net/http.serverHandler.ServeHTTP(0xc42032e480, 0xd5a700, 0xc42027e820, 0xc420730b40)
>> 	/home/whyrusleeping/go/src/net/http/server.go:2202 +0x7d
>> net/http.(*conn).serve(0xc420c1d900, 0xd5b500, 0xc4200e2a80)
>> 	/home/whyrusleeping/go/src/net/http/server.go:1579 +0x4b7
>> created by net/http.(*Server).Serve
>> 	/home/whyrusleeping/go/src/net/http/server.go:2293 +0x44d

I've tried it passing the object I get back from object.get() as well but the problems persists. What am I doing wrong?

More info

• go-ipfs v0.4.5
• node v5.5
• Mac OS X - 10.12.3

[daviddias]

Hi @thiagodelgado111, thank you for reporting these. Your timing is excellent, we just started a ipfs/docs sprint to improve all the documentation in usage of ipfs.

THe documentation for ipfs.object.addLink can be found here: https://github.com/ipfs/interface-ipfs-core/tree/master/API/object#objectpatchaddlink, you can also find some tests that showcase how it is used: https://github.com/ipfs/interface-ipfs-core/blob/master/src/object.js#L686-L730

That being said, I believe we should still support adding a link by passing the json object as you once did, it just seems that it feel through the API changes and expectations changed.

Would you like to add that support back? The steps to do it are the same as the ones described here: #535 (comment). If you don't have the availability or don't feel comfortable, don't worry, I can look into it again as soon as I have the time too :)

[thiagodelgado111]

Hi @diasdavid, thanks for helping. I think I didn't express myself correctly at first, sorry, I used to use it like this: object.patch.addLink(root, name, ref) but then I changed it to the code sample posted above after upgrading to the latest version of js-ipfs-api (interface docs are awesome btw, great work!).

I'd be happy to take a stab at adding support to it back :) I'll go through the comment you pointed me at (and probably ask a few more questions about it 😄)

Thanks once again for your help! :)

[reit-c]

I nearly created this issue last night before falling asleep, I've had quite similar problems with this function.

The documentation for object.patch.addLink specifies that the second param should be a DAGLink, but this format is never defined anywhere (that I could see) in the API. The only link there is for a DAGNode for the first param, but that links to
https://github.com/vijayee/js-ipfs-merkle-dag
which appears to be a deprecated version of
https://github.com/ipfs/js-ipfs-merkle-dag
which appears to be a deprecated version of
https://github.com/ipld/js-ipld-dag-pb

Doing my best to follow the documentation, I ended up with

const ipfsAPI = require('ipfs-api')
const ipfs = ipfsAPI()
const dagPB = require('ipld-dag-pb')

ipfs.object.new('unixfs-dir', (err, node) => {
  let link = new dagPB.DAGLink('hello.txt', mysize, 'Qmabc.....')
  ipfs.object.patch.addLink(node.multihash, link, (err, patchednode) => {
    console.log(patchednode)
  })
})

I don't know whether it's normal or expected to be importing ipld-dag-pb like that to use the object.patch.addLink function when we already have the ipfs API, though it does work.

Also as an aside, using ipfs.object.new without the unixfs-dir template string produces /ipfs/QmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n which can't be resolved (though anything patched into it can still be read). It might be helpful to have a note clarifying that unixfs-dir is not the default, which is what it currently reads as to me (since it's an optional param with only one possible value).