-
Notifications
You must be signed in to change notification settings - Fork 10
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
Loading of zarr dataset fails due to missing "ETag" in server response. #17
Comments
This is related to ipfs/kubo#8528: we need a way of telling if a CID or IPFS-path resolves to a directory or to a file (that's needed for According to the issue mentioned above, cheking the |
So apparently |
Thanks for looking into this! This is a pity, maybe we should approach them and inform them about this issue with their service. So, a quick solution would be to define the environment variable |
Revised handling of adding env variables. Note `gateway.pinata.cloud` has been removed. See this issue for more details fsspec/ipfsspec#17 (comment)
I'm currently not able to retrieve the referenced dataset anymore. However, since version 0.5.0, ipfsspec shouldn't depend on ETags anymore, thus I'd assume that this error doesn't exist anymore and I'll close the issue. |
What happened
While trying to open the dataset zarr dataset
bafybeidqwf7lcs4mo343ntgxiid7n6psvryicuqkppm3wmzad2wdamnpsu
witha KeyError is sometimes raised:
Expected behaviour
The dataset is returned without any error.
Potential causes
Debugging the above call
by inserting a few print statements into async_ipfs.py
reveals that the "ETag" is not always returned by the server. While the header looks like
for a successful request, it misses the "ETag" when failing:
Without the "ETag" the "type"-Key is not set.
ipfsspec/ipfsspec/async_ipfs.py
Lines 45 to 53 in 8eb96df
Does this mean that the success of the function call seems to depend on which IPFS peer is responding quickest?
The text was updated successfully, but these errors were encountered: