ipfs-http-client 56 yields Uint8Array chunks, but IPFS#cat() concatenates them with buffer.toString(). For a Uint8Array, toString() returns comma-separated byte values instead of text, so every document became an invalid JSON string, e.g. {"@context":... turned into 123,10,32,32,34,64,99,111,110,....
JSON.parse then failed with Unexpected non-whitespace character after JSON at position 3 (line 1 column 4), and no IPFS-backed record could be read. This surfaced in hubot-kredits as SyntaxError from contributor.jsdeserialize() on every pull_request closed hook, so no contributions were proposed anymore. It affects any Node consumer reading through the IPFS HTTP API (hubot-kredits integrations, scripts/review-kredits.js); kredits-web was unaffected because it reads via gatewayUrl.
The bug was introduced when ipfs-http-client was bumped from ^41 (Buffer chunks) to ^56 (Uint8Array chunks) in 53fafc1.
Fix
Decode the chunks explicitly with a streaming TextDecoder, which works in both Node and browsers. Bump version to 7.5.1 so consumers can depend on the fix.
Verification
Against the live stack (RSK testnet 10.1.1.20:4444, IPFS 10.1.1.198:5001), reading contributor records:
Before: cat() returned "123,10,32,32,34,64,99,..." and JSON.parse threw the error above.
After: all 21 contributors deserialize and findByAccount({ site: 'github.com', username: 'silverbucket' }) resolves correctly.
Note: this needs a new npm release (7.5.1); hubot-kredits will then be bumped to depend on it.
## Problem
`ipfs-http-client` 56 yields `Uint8Array` chunks, but `IPFS#cat()` concatenates them with `buffer.toString()`. For a `Uint8Array`, `toString()` returns comma-separated byte values instead of text, so every document became an invalid JSON string, e.g. `{"@context":...` turned into `123,10,32,32,34,64,99,111,110,...`.
`JSON.parse` then failed with `Unexpected non-whitespace character after JSON at position 3 (line 1 column 4)`, and no IPFS-backed record could be read. This surfaced in hubot-kredits as `SyntaxError` from `contributor.js` `deserialize()` on every `pull_request closed` hook, so no contributions were proposed anymore. It affects any Node consumer reading through the IPFS HTTP API (hubot-kredits integrations, `scripts/review-kredits.js`); `kredits-web` was unaffected because it reads via `gatewayUrl`.
The bug was introduced when `ipfs-http-client` was bumped from `^41` (Buffer chunks) to `^56` (Uint8Array chunks) in 53fafc1.
## Fix
Decode the chunks explicitly with a streaming `TextDecoder`, which works in both Node and browsers. Bump version to 7.5.1 so consumers can depend on the fix.
## Verification
Against the live stack (RSK testnet `10.1.1.20:4444`, IPFS `10.1.1.198:5001`), reading contributor records:
- Before: `cat()` returned `"123,10,32,32,34,64,99,..."` and `JSON.parse` threw the error above.
- After: all 21 contributors deserialize and `findByAccount({ site: 'github.com', username: 'silverbucket' })` resolves correctly.
Note: this needs a new npm release (7.5.1); hubot-kredits will then be bumped to depend on it.
ipfs-http-client 56 yields Uint8Array chunks, whose toString() returns
comma-separated byte values rather than text. Concatenating those turned
every document into an invalid JSON string ("123,10,32,..."), so
JSON.parse failed with "Unexpected non-whitespace character after JSON at
position 3" and no IPFS-backed record could be read.
Decode the chunks explicitly with a streaming TextDecoder, which works in
both Node and browsers. Bump version to 7.5.1.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
ipfs-http-client56 yieldsUint8Arraychunks, butIPFS#cat()concatenates them withbuffer.toString(). For aUint8Array,toString()returns comma-separated byte values instead of text, so every document became an invalid JSON string, e.g.{"@context":...turned into123,10,32,32,34,64,99,111,110,....JSON.parsethen failed withUnexpected non-whitespace character after JSON at position 3 (line 1 column 4), and no IPFS-backed record could be read. This surfaced in hubot-kredits asSyntaxErrorfromcontributor.jsdeserialize()on everypull_request closedhook, so no contributions were proposed anymore. It affects any Node consumer reading through the IPFS HTTP API (hubot-kredits integrations,scripts/review-kredits.js);kredits-webwas unaffected because it reads viagatewayUrl.The bug was introduced when
ipfs-http-clientwas bumped from^41(Buffer chunks) to^56(Uint8Array chunks) in53fafc1.Fix
Decode the chunks explicitly with a streaming
TextDecoder, which works in both Node and browsers. Bump version to 7.5.1 so consumers can depend on the fix.Verification
Against the live stack (RSK testnet
10.1.1.20:4444, IPFS10.1.1.198:5001), reading contributor records:cat()returned"123,10,32,32,34,64,99,..."andJSON.parsethrew the error above.findByAccount({ site: 'github.com', username: 'silverbucket' })resolves correctly.Note: this needs a new npm release (7.5.1); hubot-kredits will then be bumped to depend on it.
ipfs-http-client 56 yields Uint8Array chunks, whose toString() returns comma-separated byte values rather than text. Concatenating those turned every document into an invalid JSON string ("123,10,32,..."), so JSON.parse failed with "Unexpected non-whitespace character after JSON at position 3" and no IPFS-backed record could be read. Decode the chunks explicitly with a streaming TextDecoder, which works in both Node and browsers. Bump version to 7.5.1.