ipfs.files.add not working

[jgostylo]

I am including JS-IPFS in my browser using:

<script src="https://unpkg.com/ipfs/dist/index.js"></script>

I know that I am connecting to my running IPFS daemon using web sockets. I do an ipfs.files.cat on a resource that I know is in IPFS and it grabs it just fine. Here is my code for adding my json snippet to IPFS:

  var upload = {
    "path": "attribute.json",
    "content": new buffer.Buffer(doc)
  }

  ipfsNode.files.add([upload], function(err, res){
    if (err || !res){
      console.log("Did not add the IPFS file.", err);
    }
    else {
      res.forEach(function(file){
        addAttributeToEthRegistry(file.hash, payloadHash, type, cb);
      });
    }
  });

I know my buffer code is working. When I am in the debugger I am getting to the line inside the res.forEach and the file object has a valid IPFS address. It is just that when I attempt to cat the resource it is not there. I attempt to do this from the browser application and I attempt to cat it from the command line ipfs go client.

What am I missing? Is there a separate step to push the IPFS object to its peers after the add? I have not seen anything in the API or documentation that says that is something I should do.

[jgostylo]

Update: I ran a test to go through my code and create a dummy json structure to upload to IPFS. It worked. I tried going back to my old workflow and it once again failed. I tried hitting IPFS through the go daemon at different parts of the workflow that worked and it seems that a good work around for me is to cat the IPFS location right after I add it. The data is not available in the IPFS daemon until after I cat it in my browser application first. So if I never cat it and refresh the browser (to simulate going a user going back) the IPFS data is never actually added to the network. I believe this is a bug.

Edit: My work around did not work. It seems that while the go daemon was not able to see the IPFS doc until I did a files.cat, doing a files.cat did not propagate the data to the go daemon and then on to the rest of the network. It seems like I have to cat in the browser, then cat in the go daemon, and then the data will exist in IPFS. So I guess I go back to asking how I am supposed to push the data to my peers?

[daviddias]

@jgostylo are you 100% positive that both nodes are connected?

Make an ipfs.swarm.peers just to be sure.

[jgostylo]

Yes. I have two instances showing me that the browser is connected to the go daemon and the go daemon is connected to the outside world. I have a call in my browser that grabs something that originated from an outside source. That call works and I download the ipfs resource (it makes it all the way to the browser).

The second instance where I have seen this work is with the following workflow. I add my json doc with the browser, immediately call files.cat in the browser, once that finishes and the current browser session is still running I run the ipfs cat and it grabs the document. After that I can get the document from a global ipfs node like http://ipfs.io/ipfs/.

And ipfs.swarm.peers yeilds: /ip4/127.0.0.1/tcp/9999/ws/ipfs/QmUokpovi5QTuDpy2rBjQ1juKKLijZFgPQWLmzv2FtRqY8 as a result.

[jgostylo]

Another update:
So I constructed a new test and I have different results. The ipfs.files.cat that I was running I do not believe was necessary. I think the reason my locally running go daemon was not getting the ipfs resource was because my browser client was stopped at a breakpoint.

So if I run the cat with my IPFS daemon I will get the resource. If I run the cat from something like http://ipfs.io/ipfs/ I will not get the resource unless my go-daemon has requested it first. So it looks like I need to find a way to force push the doc to my go daemon. How does that work?

Just to be clear I would say that ipfs.files.add is working. I just don't know how to force the propagation to my peers.

[daviddias]

Hi @jgostylo, apologies for lack of response here. Could you try to give this another spin with a fresh npm install? Thanks!

[daviddias]

@jgostylo this shouldn't be an issue anymore. Let me know if that is not the case to continue investigating :)