Skip to content
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

files.cat and object.links / object.data fail on some files they should work on #1258

Open
mitra42 opened this issue Mar 11, 2018 · 6 comments
Labels
exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) need/triage Needs initial labeling and prioritization P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked

Comments

@mitra42
Copy link

mitra42 commented Mar 11, 2018

  • Version: 0.28.1
  • Platform: OSX 10.13.3, Node v8.8.1
  • Subsystem: files.cat and object.links/object.data

Type: Bug

Severity: High

Description: files.cat or object.links, object.data dont work on some links they almost certainly should do.

Steps to reproduce the error:

See the attached file which can be run with

mv test_ipfs_video.js.txt test_ipfs_video.js   # Because git wont let me attach a .js
[test_ipfs_video.js.txt](https://github.com/ipfs/js-ipfs/files/1800152/test_ipfs_video.js.txt)

node test_ipfs_video.js

it tests retrieving two different files via files.cat and via the object.links, object.data sequence used in 8f8c539
One file works, the other fails.

The differences / similarities.
Both are retrievable via the gateway
PDF https://ipfs.io/ipfs/Qmbzs7jhkBZuVixhnM3J3QhMrL6bcAoSYiRPZrdoX3DhzB
VIDEO https://ipfs.io/ipfs/zdj7Wc9BBA2kar84oo8S6VotYc9PySAnmc8ji6kzKAFjqMxHS
Both are multi-block, the first has 2 links, the second 46
The PDF was uploaded via http with /api/v0/add maybe 6 months ago
The VIDEO was uploaded via http with /api/v0/urlstore about 2 months ago

The PDF is retrieved successfully with either files.cat or object.links / object.data (see the code for what I mean by this)

On the VIDEO
files.cat fails with Failed to unmarshal node
object.data returns undefined on the first block of the video

I don't think the difference is PDF v VIDEO since its not accuracy of the data that is the issue, its the failure to retrieve it at all with files.cat

@daviddias
Copy link
Member

daviddias commented Mar 12, 2018

@mitra42 are you 100% sure that the file was added with files.add? Looks like it is trying to unmarshall non unixfs protobuf. Thanks for the repro case :)

@daviddias daviddias added exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked labels Mar 12, 2018
@mitra42
Copy link
Author

mitra42 commented Mar 13, 2018

Not with files.add, I'm 99% sure the failing file was added with urlstore as that was the switch from Q* to z* hashes, I don't know how the successful one was added (could have been files.add or dag.put).

To be certain I tried two more files, one added a couple of days ago and the other I just added. Both were added via the http api to urlstore. The weird thing is that one fails in the object.data (retrieves undefined) and the other fails in unmarshal (returns undefined). All of these files except the PDF fail in files.cat

See attached - same instructions, rename to test_ipfs_video.js and run node test_ipfs_video.js
test_ipfs_video.js.txt

@kyledrake
Copy link

kyledrake commented Mar 23, 2018

This I believe is related to the urlstore code not currently renewing DHT provides automaticaly, so we're working on adding this functionality through a different process for the root CIDs.

@momack2 momack2 added this to Ready in ipfs/js-ipfs May 10, 2019
@momack2 momack2 added this to Ready in ipfs/js-waffle May 10, 2019
@autonome
Copy link
Contributor

autonome commented May 21, 2020

@mitra42 is this is still a problem with contemporary IPFS?

@mitra42
Copy link
Author

mitra42 commented May 23, 2020

Hi - sorry, I don't know, This was over 2 years ago, so my memory is fuzzy and I haven't touched IPFS code for a while (its been turned off in dweb.archive.org for a long time by default because of other bugs/issues)

My vague memory is that Kyle was probably correct (a DHT scaling problem with IPFS which AFAIK was never fixed, and was part of why we dropped trying to keep the IPFS gateway alive).

I do see workarounds for odd problems in https://github.com/internetarchive/dweb-transports/blob/master/TransportIPFS.js#L334 and that might have been related.

Sorry I can't be of more help.

@jacobheun jacobheun added the need/triage Needs initial labeling and prioritization label Jun 18, 2020
@autonome
Copy link
Contributor

autonome commented Jun 18, 2020

Thanks @mitra42.

Triaged - need someone to update the testcase, and re-run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) need/triage Needs initial labeling and prioritization P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
No open projects
Development

No branches or pull requests

5 participants