0.4.14-rcX fails js-ipfs-api test suite

[Kubuxu]

Reference ipfs-inactive/js-ipfs-http-client#486 (comment)

Test output: https://friendpaste.com/72TbssZSoSxmdOpKxT67je

[magik6k]

I've done few more runs:

On 0.4.13:

• https://hastebin.com/pixokuqaxi.vbs

On 0.4.14-rc2

• https://hastebin.com/sesacejiye.vbs
• https://hastebin.com/omuhesuwip.vbs
• https://hastebin.com/molexizoji.vbs

[Kubuxu]

@victorbjelkholm @diasdavid could we get some help interpreting these.

I see that there are some that are false positive lookalike. Like the [] vs [null].

[magik6k]

Changes I see:

• bitswap/wantlist now returns {"Keys":[]} instead of {"Keys":null} for empty wantlist
• files/stat fail is caused by changes in add support for ipfs files stat --with-local ipfs-inactive/js-ipfs-http-client#695 and slightly wrong testcase. on 0.4.14-rc2 files/stat returns:

{
  "Hash": "Qm...",
  "Size": 1088,
  "CumulativeSize": 1099,
  "Blocks": 0,
  "Type": "file"
}

and with --with-local:

{
  "Hash": "Qm...",
  "Size": 1088,
  "CumulativeSize": 1099,
  "Blocks": 0,
  "Type": "file",
  "WithLocality": true,
  "Local": true,
  "SizeLocal": 1099
}

• Not sure about DHT fails, it happened on 0.4.13 too
• pubsub/sub returned an empty object ({}) after request, this has been fixed in 0.4.14-rc2
• The other errors seem to be related to the fact that some tests failed.

[daviddias]

Try with https://github.com/ipfs/js-ipfs-api/releases/tag/v18.1.2 test suite. Currently js-ipfs-api Master is in flux due to many Windows + other fixes that were happening in parallel and complicating things, next week it will be golden again.

[magik6k]

Tried with js-ipfs-api 18.1.2 + go-ipfs 0.4.14-rc2, fails mostly in the same ways as the master: https://hastebin.com/gigiforudu.vbs

[whyrusleeping]

@victorbjelkholm can we get some automated CI for running js-ipfs-api tests?

[magik6k]

For 0.4.13 / js-api 18.1.2 there is only a single test failing, prorbaly a random fail: https://hastebin.com/eticutoyal.vbs

[magik6k]

I tried to find a difference between files/stat on 0.4.13 and 0.4.14-rc2:

0.4.14-rc2:

HTTP/1.1 200 OK
Access-Control-Allow-Headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
Access-Control-Expose-Headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
Content-Type: application/json
Server: go-ipfs/0.4.14-rc2
Trailer: X-Stream-Error
Vary: Origin
X-Chunked-Output: 1
Date: Thu, 15 Mar 2018 18:58:30 GMT
Connection: close
Transfer-Encoding: chunked

71
{"Hash":"Qma4hjFTnCasJ8PVp3mZbZK5g2vGDT4LByLJ7m8ciyRFZP","Size":12,"CumulativeSize":20,"Blocks":0,"Type":"file"}

0

go-ipfs/0.4.13:

HTTP/1.1 200 OK
Access-Control-Allow-Headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
Access-Control-Expose-Headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
Content-Type: application/json
Server: go-ipfs/0.4.13
Trailer: X-Stream-Error
Vary: Origin
Date: Thu, 15 Mar 2018 19:23:02 GMT
Transfer-Encoding: chunked

75
{"Hash":"QmcPGG45AEWEG1PCeufXDDsGWb3QE1MoCdzuH1AwN3u5Ft","Size":1088,"CumulativeSize":1099,"Blocks":0,"Type":"file"}

0

The only difference is the removed Connection: close, so one explanation I have for it is that it may cause problems with keep-alive on js-ipfs-api side.

[victorb]

Looked into the test failures from js-ipfs-api v18.1.2 with go-ipfs 0.4.14-rc2

• bitswap wantlist changes: from Keys: null to Keys: [], easily fixed and would be on js-ipfs-api side. I recommend to note this as a breaking change in the release notes in case libs are assuming null instead of [].
• files.stat somehow weird values
  • go-ipfs cli works fine
  • go-ipfs http api works fine
  • only difference is X-Chunked-Output: 1 which is introduced with 0.4.14
  • probably bug regarding parsing response in js-ipfs-api
• .files mfs (interface-core-ipfs) are screwed with as well
  • probably because parsed the same way as files.stat
• pubsub is generally broken (~40% of tests passes) it seems, haven't looking into on go-ipfs or js-ipfs-api side yet.

[Kubuxu]

Seems like X-Chunked-Output: 1 is a new header for some commands.

It is introduced in go-ipfs-cmds here:
https://github.com/ipfs/go-ipfs-cmds/blob/13acd1ab00ea043c3b202e1eb0fca2dec1a34a34/http/responseemitter.go#L207-L212

It is controlled by https://github.com/ipfs/go-ipfs-cmds/blob/master/responseemitter.go#L10-L14 and our mistake is not using EmitOnce or Emit(Single{var}) for emitting single values.

From another side, sending even chunked response with single chunk should not break the js-ipfs-api.

I am fixing this but please harden js-ipfs-api parsing.

[victorb]

@Kubuxu thanks, I can confirm that 5917805 does indeed fix the files.stat calls in js-ipfs-api and got the tests to pass with that commit applied.

Will continue looking into the pubsub issues now.

[victorb]

Regarding pubsub, this is what I see when testing pubsub ls with 0.4.14-rc2-59178057a so I'm guessing the test failures are expected.

$ ipfs daemon --enable-pubsub-experiment # in one terminal

$ ipfs pubsub sub test # in another terminal

$ ipfs pubsub ls # in yet another terminal, but gives output:
Error: not of type error

[Kubuxu]

Fixed pubsub ls in 42d1aa5
It was broken by cmds refactor when the output format was changed.

[victorb]

So with @Kubuxu's fixes, I've been able to get green tests for node tests on js-ipfs-api. This is the only change required on js-ipfs-api's side: ipfs-inactive/js-ipfs-http-client#718

Currently running browser+webworker tests, but should be fine.

$ ./node_modules/go-ipfs-dep/go-ipfs/ipfs version --all
go-ipfs version: 0.4.14-rc2-90017e9da
Repo version: 6
System version: amd64/linux
Golang version: go1.10

[victorb]

So, seems like the tests are all passing with 90017e9 and ipfs-inactive/js-ipfs-http-client#718, even in the browser and webworker.

Great work @Kubuxu for quick fixes and @magik6k for debugging awesomeness! 👍

[whyrusleeping]

This is resolved now