Open rampall opened 1 month ago
I see that error when an entire /bytes reference cannot be retrieved. Do you mind providing the full reference and which swarm (mainnet or testnet) it is on?
As per of https://github.com/axios/axios/issues/4806, taking @ldeffenb 's comment into consideration, it may be that this is a lying error message when something else fails downstream.
I see that error when an entire /bytes reference cannot be retrieved. Do you mind providing the full reference and which swarm (mainnet or testnet) it is on?
317d3cfd96206a627f7985f694f11022c599723753afd838f829a5bb53b2f389 on mainnet
Yep, swarm-cli gives the reference to the file:
swarm-cli manifest list 317d3cfd96206a627f7985f694f11022c599723753afd838f829a5bb53b2f389
d56ef37eea74dbdc60412525439922f2adaa35b62f0aaa1ae6a57aa1fc4bdabb /linuxmint-20.1-cinnamon-64bit.iso
But curl says that it's not fully retrievable, in fact, LOTS of bytes remaining to be read:
curl http://localhost:1633/bytes/d56ef37eea74dbdc60412525439922f2adaa35b62f0aaa1ae6a57aa1fc4bdabb
curl: (18) transfer closed with 834961150 bytes remaining to read
axios will give you the maxContentLength
error if you try to retrieve the d56ef...dabb
reference with the /bytes
endpoint, or the filename included in a /bzz
reference which amounts to the same retrieval after the manifest entry has been resolved.
Interesting.
The stewardship endpoint however returned isRetrievable: true
for me (although it took like 9 minutes or so)
/stewardship
lies. See https://github.com/ethersphere/bee/issues/4696 It doesn't check that the actual leaf data nodes are actually retrievable. Only actually fetching the data does that.
That said, a -X PUT /stewardship/{reference}
WILL push all required chunks, even the data leaves. It's really good if you originally pinned the content. Not so good if it has to retrieve the chunks to re-push. In the latter case, this reference will likely fail.