http-client dag.put failed with invalid byte #3914
Comments
|
Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
Finally, remember to use https://discuss.ipfs.io if you just need general support. |
|
@achingbrain the DAG API is now out of sync between go-ipfs and js-ipfs-http-client and errors like this are going to start popping up. This particular error is going to be about the codec defaults, and what's more, the arguments have changed. The default Defaults and options need to be updated here to match 0.10. I just don't know how you deal with the version mismatch if someone's using 0.9, but maybe you just don't? https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#v0100-2021-09-30 |
We've not addressed this before - if people are using the older version of It could probably use a table in the README saying which versions of the client are compatible with which versions of |
|
This is the latest version of js-ipfs and go-ipfs. A chart would be great. Everything works fine before 0.10. Thanks for checking into this! |
lidel
added
kind/maintenance
Fixes: #3914 Ref: https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#v0100-2021-09-30 --format and --input-enc have been replaced with --input-codec and --store-codec and mean something a little different. You now supply raw input and instruct the server which --input-codec that data is in which it will decode, then re-encode with --store-codec before storing it and providing you with the CID. We accept plain JavaScript objects to encode with --store-codec via the API here, defaulting to dag-cbor, and send that to the server as encoded bytes using that codec, to be stored using that codec. If you supply an --input-codec then we assume you're supplying raw, encoded bytes using that codec and we pass that directly on to the server to handle.
Fixes: #3914 Ref: https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#v0100-2021-09-30 --format and --input-enc have been replaced with --input-codec and --store-codec and mean something a little different. You now supply raw input and instruct the server which --input-codec that data is in which it will decode, then re-encode with --store-codec before storing it and providing you with the CID. We accept plain JavaScript objects to encode with --store-codec via the API here, defaulting to dag-cbor, and send that to the server as encoded bytes using that codec, to be stored using that codec. If you supply an --input-codec then we assume you're supplying raw, encoded bytes using that codec and we pass that directly on to the server to handle.
Fixes: #3914 Ref: https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#v0100-2021-09-30 --format and --input-enc have been replaced with --input-codec and --store-codec and mean something a little different. You now supply raw input and instruct the server which --input-codec that data is in which it will decode, then re-encode with --store-codec before storing it and providing you with the CID. We accept plain JavaScript objects to encode with --store-codec via the API here, defaulting to dag-cbor, and send that to the server as encoded bytes using that codec, to be stored using that codec. If you supply an --input-codec then we assume you're supplying raw, encoded bytes using that codec and we pass that directly on to the server to handle.
Fixes: #3914 Ref: https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#v0100-2021-09-30 --format and --input-enc have been replaced with --input-codec and --store-codec and mean something a little different. You now supply raw input and instruct the server which --input-codec that data is in which it will decode, then re-encode with --store-codec before storing it and providing you with the CID. We accept plain JavaScript objects to encode with --store-codec via the API here, defaulting to dag-cbor, and send that to the server as encoded bytes using that codec, to be stored using that codec. If you supply an --input-codec then we assume you're supplying raw, encoded bytes using that codec and we pass that directly on to the server to handle.
Fixes: #3914 Ref: https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#v0100-2021-09-30 --format and --input-enc have been replaced with --input-codec and --store-codec and mean something a little different. You now supply raw input and instruct the server which --input-codec that data is in which it will decode, then re-encode with --store-codec before storing it and providing you with the CID. We accept plain JavaScript objects to encode with --store-codec via the API here, defaulting to dag-cbor, and send that to the server as encoded bytes using that codec, to be stored using that codec. If you supply an --input-codec then we assume you're supplying raw, encoded bytes using that codec and we pass that directly on to the server to handle.
Fixes: #3914 Ref: https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#v0100-2021-09-30 --format and --input-enc have been replaced with --input-codec and --store-codec and mean something a little different. You now supply raw input and instruct the server which --input-codec that data is in which it will decode, then re-encode with --store-codec before storing it and providing you with the CID. We accept plain JavaScript objects to encode with --store-codec via the API here, defaulting to dag-cbor, and send that to the server as encoded bytes using that codec, to be stored using that codec. If you supply an --input-codec then we assume you're supplying raw, encoded bytes using that codec and we pass that directly on to the server to handle.
Severity: Medium
Description: Running await ipfsClient.dag.put({"hello": "world") fails with an error of [Uncaught HTTPError: Invalid byte while expecting start of value: 0x5a]. Issue was not present before IPFS Desktop updated to 0.10.0
Steps to reproduce the error: Connect to local ipfs-go instance and attempt to put a DAG of {"hello": "world"}.
The text was updated successfully, but these errors were encountered: