findprovs returns object or string

[victorb]

using the method ipfs.dht.findprovs in node environment does not work like one would expect. Using the following code:

var ipfsAPI = require('ipfs-api')

var ipfs = ipfsAPI('localhost', '5001')

const hash = "QmXFmCEhamPHvpbzQ3HMFABrpAXgE7D9jzp6QtvyC8Xp55"

ipfs.dht.findprovs(hash, (err, res) => {
    if(err) throw err
    console.log(res)
    console.log(typeof res)
    console.log("Streamable?", !!res.readable)
    console.log('So what to do with `res` here?')
})

I get the following output sometimes (which works correctly):

object
Streamable? false
So what to do with `res` here?

but other times, it returns this (which is neither streamable or valid json)

string
Streamable? false
So what to do with `res` here?

Originally open issue ipfs/kubo#1851 on go-ipfs but seems to be a bug in this library.

[victorb]

Tried using node-ipfs-api in browser and seems to always return a string of json stream... Not sure how to handle this. Take a look here for quick demo: victorb/webpack-node-ipfs-api-demo@c3dc5e2

[daviddias]

following the IRC discussion -> We need proper Node.js and Browser tests, testing every API call, so that the interface gets polished (#57), otherwise it will feel that we are always chasing one more little thing.

Thank you for catching this @victorbjelkholm. If someone wants to go ahead and bring that, it will be very appreciated :)

[fazo96]

I'm building an application on top IPFS and just ran into this problem. I read a little bit and if I understand correctly this bug will be fixed by solving #87 right?

Sorry to bother, just trying to get an estimate for the solution

[daviddias]

@fazo96 right now, this depends on what the API returns, if the IPFS node decides that has enough stuff to stream it, js-ipfs-api will return a stream, otherwise it will return a String, the decision is made on this flag - https://github.com/ipfs/js-ipfs-api/blob/master/src/request-api.js#L63

@whyrusleeping is there any option to choose the mode explicitly?

[dignifiedquire]

I think there should be explicit options so api users can decide how they want to consume the results.

[victorb]

@dignifiedquire in that case, we should provide both ability to set stream/object in all methods and for individual ones.

[dignifiedquire]

@victorbjelkholm exactly, so that it's predictable, at the moment it's more guessing than anything.

[daviddias]

Is this still a issue with the latest changes? Could you confirm @victorbjelkholm ?

[dignifiedquire]

Sorry, the issue is that some commands return an array and some return a single object depending if run from the browser or from node

[fazo96]

This is still an issue on the latest version as of now. Findprovs returns a string with multiple json documents and there's no easy way to parse it because you would have to cut it when a document finishes and another one starts, I don't think it should be like that.

Maybe return an array of strings or a stream where each element is a parsable json?

[daviddias]

@fazo96 are you using IPFS 0.3.9? That sounds like IPFS 0.3.8 (which didn't use ndjson)

[fazo96]

I'm using IPFS 0.3.9 and js-ipfs-api 2.9.0 (just updated it). I'm afraid the problem remains, but I guess I can apply ndjson.parse() myself so it's not a big deal

[dignifiedquire]

The issue is two fold, 1) go-ipfs returns a different format in the browser 2) that format is invalid json, so it has to first be fixed there: ipfs/kubo#1978

[dignifiedquire]

Turns out this is a bug on our side..We are not properly all headers, resulting in the wrong handling of the response.

[dignifiedquire]

Real problem

because of the great spec on “fetch” https://fetch.spec.whatwg.org/#concept-filtered-response-cors when doing cross origin requests and wanting to access custom headers on the request they need to be listed by the server using the header field “Access-Control-Allow-Headers”: https://fetch.spec.whatwg.org/#http-access-control-expose-headers