I use kubo as a dependency library and run it on the local lan network.
My expect:
I want to download files through IPFS, and when the file does not exist, I hope the core api immediately return.
When the file exists, download it using the timeout given by ctx.
Or in other words, The Get API Can use two ctx, one is used to detect file exist or not, the other for
download timeout.
NOW:
I found that when get a non-existent CID through the core API, it will hang and not return.
Is there any way to determine if a CID does exist or not and return in a custom timeout ctx.
It is not possible to 100% know the CID does not exist in public swarm. Someone may have it, but be offline at the time of your check etc. The best you can do is to wrap ctx with a timeout. that makes sense for your use case. This way it does not hang forever.
If you only want to check local existence, you could run node in offline mode and confirm if requested CID exists in local repository.
It is also possible to do local ad-hoc check via ipfs block stat CID --offline, which will error if the block is not already in local blockstore (will not attempt to retrieve it from other peers).
Programmatic equivalent of --offline is to wrap blockstore with offline Exhange:
With this your operations will only check local store and avoid making p2p requests.
@lidel Thanks for your answer.
I tend to use timed out context.
But now I am confused about the purpose of the ctx parameter of the Get method in the core API.
Does the timeout of this ctx refer to the search phase, download phase or total.
In my scenario, I only want the timeout context to take effect during the search phase.
I want to determine whether the file exists as soon as possible (allowing for inaccuracies) and start downloading.
The download phase may take a long time due to the large size of the file, so the timeout period do not take effect during the download phase, or provide an additional timeout for the download phase.
It applies to entire Get operation. What happens inside, that is up to your implementation.
That is why I suggested you have a separate instance built with offline Exhange.
We are missing local-only API, so you need to create one yourself.
This way you know that the timeout applies only to search phase, because there won’t be any retrieval.
