Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'add' command doesn't return the CID for the added data. #3

Open
vasa-develop opened this issue May 8, 2019 · 8 comments
Open

'add' command doesn't return the CID for the added data. #3

vasa-develop opened this issue May 8, 2019 · 8 comments
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws)

Comments

@vasa-develop
Copy link
Collaborator

vasa-develop commented May 8, 2019

In v0.0.3 when we do:

cluster.add(CID, (err, res) => {
    console.log(res)
})

We get an empty array: []

Somehow we aren't getting the CID object(which can be accessed using a normal POST request).

Here is what I have found:

  • On running the test for 'add', this line is supposed to get the CIDs. But it's NOT getting any CIDs.
@vasa-develop vasa-develop added kind/bug A bug in existing code (including security flaws) help wanted Seeking public contribution on this issue labels May 8, 2019
@hsanjuan
Copy link
Collaborator

hsanjuan commented May 8, 2019

I think the problem is here: https://github.com/ipfs/js-ipfs-http-client/blob/master/src/utils/file-result-stream-converter.js#L38

That converter is expecting "add" objects as IPFS returns them, but cluster returns slightly different ones ("hash" is "cid" and "size" is a number and not a string).

@vasa-develop
Copy link
Collaborator Author

vasa-develop commented May 8, 2019

I think the problem is here: https://github.com/ipfs/js-ipfs-http-client/blob/master/src/utils/file-result-stream-converter.js#L38

That converter is expecting "add" objects as IPFS returns them, but cluster returns slightly different ones ("hash" is "cid" and "size" is a number and not a string).

What a coincidence...I just found this too ;)

It's working now! BTW, thanks for the quick response.

add-test

vasa-develop added a commit that referenced this issue May 8, 2019
@d7laungani
Copy link

d7laungani commented Jan 27, 2020

i am having this same issue in v0.09 @vasa-develop

@marwyn-the-developer
Copy link

marwyn-the-developer commented Mar 16, 2020

I am also facing the same issue in v0.0.9. The answers provided are not comprehensive since the link returns a 404 message.

@hsanjuan hsanjuan reopened this Mar 16, 2020
@hsanjuan
Copy link
Collaborator

hsanjuan commented Mar 16, 2020

@vasa-develop any ideas?

@danazkari
Copy link

danazkari commented Jun 8, 2020

I'm also having issues if I try to send just the buffer, instead I had to send an object with a path key, eventhough that key value is not used for anything useful in the IPFS context

const res = await ipfs.add({path:'dummy-name', content: fileBuffer})
// res -> [ { path: 'dummy-name', hash: '...', size: 15 } ]

So for now that's what I'm doing, because if I give it just the buffer, then it just returns an empty array.

Hope this helps someone!

@vasa-develop
Copy link
Collaborator Author

vasa-develop commented Jun 14, 2020

sorry guys, my notifications were turned off. So I missed the messages

@NadeeraM
Copy link

NadeeraM commented Dec 22, 2020

I commented following if condition in FileResultStreamConverter and then it works. But not sure why that constrain is there.
In _transform ->

if (!obj.name) {
return callback()
}

Then it returns object with empty path attribute.

[ { path: '',
hash: 'QmRHza6PjWyFpCdPZcafRybrjyaqQC2fnNfNesd7oEirid',
size: 22 } ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws)
Projects
None yet
Development

No branches or pull requests

6 participants