Gateway Timeout. Urgent help!

Hello everyone,
Please, help me!

import CID from ‘cids’ ;
import { create as ipfsHttpClient } from ‘ipfs-http-client’ ;

// const client = ipfsHttpClient(‘https://ipfs.infura.io:5001/api/v0’,) ;

export const ipfs_origin = ‘https://ipfs.infura.io/ipfs/’;

// upload flow
let added = await client.add(
file.raw,
{ progress : async (prog) => {
}) ;

[ **********sol.data().ipfs_sol_hash <= added.path ]

// get file flow
let sol_meta = await axios.get(ipfs_origin + sol.data().ipfs_sol_hash ) ;

let asset_url = ‘https://’ + new CID(sol_meta.data.ipfs_asset_hash).toV1().toString(‘base32’) + “.ipfs.infura-ipfs.io”;

This is my customer console.log .

50% of customers in our company can upload and download file successfully using this code.
But and the rest of 50% can’t it.
This is urgent help!

Hi,
I have confirmed that there is a 10 minute timeout (for authenticated get requests - unauthenticated timeout is much lower at 1 minute). Just a note - assuming I can get a 50Gbit/s transfer rate end to end, that’s about 3TB. That’s a very large file indeed. Perhaps you can split such large files up and upload them separately if you need to.

I tried to run up a local ipfs daemon and request your CID from there, hoping that the peer to peer nature of ipfs would allow the file to be replicated to my local machine where I could use “ipfs get CID” to get it and at least find out how big it is. However it has not worked. Looking further I tried:
ipfs dht findprovs QmUi7NADhp9NEzgf8rVjSjq8XMmXxV4hN9rMoAx1SxEzZ8
but it returns nothing. This indicates to me that that CID is not available anywhere on the IPFS peer to peer network and this might be the problem. I tried several other random CIDs (non-existent) and they also don’t return anything.

It might not be the size of the file that is the problem but rather that it doesn’t exist on IPFS for some reason. Can you see it pinned in your Infura IPFS project?

I hope this helps you solve your issue, I’d be grateful if you can let us know the outcome.

Warm regards,
Chris | Infura | ConsenSys

Thank you @chris.paterson .

Actually, this file is small pdf file.
Sometimes, I get this file without gateway timeout error.
I tried many time to get file, through this I only get file successfully 2 time.
From this, we can know that file is existed in on ipfs.

My guess is that depending on where users upload their files, there’s something wrong with the Gateway.
In fact, 50% of customers can freely upload and download files through this code without any problem, and get accurate file information through CID.

I noticed another new thing, among users who have this issue, uploading data in json format is successful, but only uploading and downloading files is unrealistic.

  1. why isn’t is possible about 50% of customers?

  2. Please, indicate wrong part in our code.
    maybe code is correct.
    As I mentioned above, 50% of customers are using this code without any problem.

  3. If it is failed, why ipfs hash value is returned after uploading?

  4. I have got some solution through some topic.
    I get result from them that I should register our ipfs project to infura.io.

I am not using infura ipfs project.
As you can see, infura project id or project secret key is not integrated in our code.
We are going to use ipfs on free.
For this, should we register our project to infura.io?

Hi Christopher,

I can’t comment on your code as the only code you show is not a working example. If you can send a github repo showing your full system I might be able to help there. I can’t see why 50% of customers have no problems without the full picture.

Certainly you should create a project in Infura and use the project ID and project key to authenticate your requests. Using the public gateway is handy but is not for production code. You should instead use authenticated requests to the Infura/IPFS API. This should improve things.

Note that I’m not sure what happens when you add a file to the Infura/IPFS service unauthenticated. By default the file is also pinned when it’s added but when unauthenticated I can’t guarantee that the file will be available forever. The bottom line - you must be authenticated. I suggest you start there.

Warm regards,
Chris | Infura | ConsenSys

Thank you @chris.paterson
We registered our project to infura.io.
It is successful !

2 Likes

@chris.paterson
I want to delete and edit file on ipfs.
Actually, I know It is impossible.
But I saw some blogs about " Ipfs unpin ".
Can you provide it with nodejs code?

Hi Christopher,

You can download a file from IPFS and then edit it and upload it again. But then you’d have two files - one addressed by the old CID and the new one with a new CID. So if you gave the old CID to someone, or referred to it, say in a webpage, then you’d have to give out the new CID to replace the old CID of the previous version. It’s a built-in problem with IPFS.

Pinning is not related to this problem (sorry if I miss-understand you). When a file is “pinned to a node” or to a pinning service (like Infura or pintana) then it’s protected from being cleaned up in a garbage collector run.

So, pinning is only related in that you’d unpin the old CID so that it get’s deleted eventually by the garbage collector because you don’t need it anymore. In fact you’d probably just delete the file once the new one is up and all the references to it are replaced by the new CID.

hope this helps.

Warm regards,
Chris | Infura | ConsenSys

Thank you @chris.paterson
For example,
Suppose user upload file to ipfs and he/she get “Qm123…”.
And user post this CID to other user.
At this time, If this CID is reported to another users, this file is not secret any more.
If the user wants to make this file private again…
To do this, the user will encrypt this file and upload it to IPFS with a new CID.

we have already make above flow.

From now.
At this time, the old CID to which this file has already been uploaded should not be used any more.
This old CID is issue for us.

Hi,
it sounds like you should unpin the old CID from IPFS. The distributed nature of IPFS means that the old CID may be accessible for some time somewhere in the network but eventually all nodes will delete it from their caches.

Warm regards,
Chris | Infura | ConsenSys

Thank you @chris.paterson