Conversation
|
@Stebalien @whyrusleeping did you run the interop tests as part of the release or any of the RCs? |
|
@diasdavid My C# HTTP API tests are all passing with go-ipfs 0.4.16. In fact a few tests are now working! It now handles
|
|
Update, seems that PubSub is good. It just so happened that the exchange files test failures were interfering with the PubSub ones |
|
I'm only seeing failures specifically on moving files from Playing with the timeouts, I can see more of the tests |
| describe('repo', () => { | ||
| // The repo was again changed on go-ipfs 0.4.16 | ||
| // TODO: create spec tests for repo | ||
| describe.skip('repo', () => { |
|
I did. As usual, they failed due to repo differences. |
The issue there was in |
That's worrying. Is this new (not in go-ipfs 0.4.15)? See: ipfs/kubo#5183. |
|
So, I added a |
|
Found it: ipfs/js-ipfs#1445. Basically, we're sending a block and then waiting for an EOF before sending the next block. There are two issues here:
|
|
|
I'm confused by the logic here. Are you saying you want a EOF (aka FIN packet in networks land) for each block you send out? If so, that breaks the streams abstraction as a stream that got closed/finalized should not be reused.
@magik6k any ETA for a release of that fix? |
I'm saying that, when go sends a block and then closes the stream (for writing), it expects the other node to also close the stream (for writing) to completely close it. This was still was still a bug in go as there's no reason to wait for the EOF from JS before sending off the next block, but JS should eventually send that EOF. |
|
It's all good and shiny again!!! :D Note the numbers. go-> js is 2x of js-> go and js->js. |

I'm seeing a lot of failures with go-ipfs 0.4.16
Exchanging files
Seems that now exchanging files is prone to hang until timeout
PubSub
Seems that the http-api response format for PubSub was changed as well