ipfs.dag.get broken

[CSDUMMI]

• Version: ^0.55.1

• Platform: Linux x64

• Subsystem: dag

Severity: Critical

Description:

I executed this line:

ipfs.dag.get("bafyreic7w5xoi64ktxhrrqy3ezl3gbrip4ftlcpp37miovw4s5o3pnqj2y").then(console.log)

And got this error:

Uncaught TypeError: Cannot read property 'length' of undefined
    at encode (node_modules/multibase/src/rfc4648.js:71:28)
    at Object.encode (node_modules/multibase/src/rfc4648.js:111:14)
    at Base.encode (node_modules/multibase/src/base.js:33:23)
    at toString (node_modules/uint8arrays/to-string.js:45:29)
    at blockEvent (node_modules/ipfs-bitswap/src/notifications.js:23:38)
    at Notifications.wantBlock (node_modules/ipfs-bitswap/src/notifications.js:68:22)
    at Bitswap.get (node_modules/ipfs-bitswap/src/index.js:276:26)
    at BlockService.get (node_modules/ipfs-block-service/src/index.js:97:28)
    at IPLDResolver.get (node_modules/ipld/src/index.js:155:33)
    at get (node_modules/ipfs-core/src/components/dag/get.js:31:25)

Steps to reproduce the error:

Install v0.55.1 or higher of ipfs from npm and execute the line above.

[TheDiscordian]

FWIW on my end (version checked /w ipfs.version()) I don't experience this with v0.5.4, but I do with v0.6.0.

[CSDUMMI]

ipfs.version() (in contradiction with my package.json file) also gives me the version 0.6.1.

So it happend somewhere between 0.5.4 and 0.6

[CSDUMMI]

In the Changelog for 0.55.0 it states:

• only accept cid for ipfs.dag.get (#3675) (bb8f8bc), closes #3637

[CSDUMMI]

@TheDiscordian I was wondering, whether there was any update on this issue?

[negamaxi]

Faced similar issue

This code works in v0.54.4:

// cid = "bafyreihy62eeywxxp5mvwy7y6wddcnpopulnqsuurk2pwnlow7fj3aql6m"
await ipfsNode.dag.get(cid);

In v0.55.2 it produces error with a following traceback (CRA fallback screen)

I can fix this by passing instance of CID instead of a raw string:

// cid = "bafyreihy62eeywxxp5mvwy7y6wddcnpopulnqsuurk2pwnlow7fj3aql6m"
await ipfsNode.dag.get(new CID(cid));

[negamaxi]

Ok, i see now it was intentional change to accept only instances of CID in dag.get.

[CSDUMMI]

Yes. But that does not mean it was the right decision.

[Tumble17]

Really glad this was raised and answered. Would love to be able to further understand this relationship with IPFS. I saw in the tutorial a note of 'These are all stored in the global IPFS network so you can find any piece by visiting a public gateway such as ipfs.io and adding the IPFS multiaddress to the end of the URL'

With the use of get(new CID) rather than raw get(cid), I get a hash of 'null' in the payload, does anyone know if there's a way to interact with IPFS addresses with any other part of the payload or why the value is null, anything I can do about this?

[lidel]

Ack, this changed long time ago – ipfs.dag.get expects a CID instance.

In the future, when in doubt, refer JS API docs at:
https://github.com/ipfs/js-ipfs/blob/master/docs/core-api/DAG.md#ipfsdaggetcid-options