Conversation
|
Are we not using protocol/.github#487 in this repo? |
No, this repo uses gated releases instead of releasing on every change to master: #1589 |
|
From the CI error it looks like the job just needs to install some extra deps? |
|
Thinking about it a bit more, Webkit is Webkit so do we need to run it on both? Running it on Linux means it'll pull the cached deps from the |
Not the actual error. Just the error in CI. This has failed on me on a linux with the correct deps installed. |
a9e5026 to
5a00304
Compare
|
The failure is when we do something like this: |
|
Possibly related: https://bugs.webkit.org/show_bug.cgi?id=169468#c1
Edit, nvm it seems like that has been done. |
|
Aha! it turns out webkit+linux doesn't like it when you import a key with no bytes. e.g. this works: Confusingly, this error happens when you try to use the imported key with |
102ecfd to
1fd8276
Compare
1fd8276 to
c3cde5e
Compare
|
This is blocked on libp2p/js-libp2p-crypto#319 |
test/autonat/index.spec.ts
Outdated
| stream.sink.returns(Promise.resolve()) | ||
|
|
||
| // stub autonat protocol stream | ||
| const stream = stubObject<Stream>({ |
There was a problem hiding this comment.
Trying to run this branch locally I noticed something weird with the stubbing but only in WebKit, though I didn't get to the bottom of it.
We stub a bunch of peer responses in each test to simulate different scenarios - once a certain number of tests were being run, the stubbed return values started being from the wrong tests.
Needs more investigation really.
There was a problem hiding this comment.
Yes. Hence this change. I'm not sure why exactly this fails on WebKit but seems to work on other browsers. I'm not sure overriding values is supported in Sinon or if it's a hack we do. The change here is to not override and instead be explicit in what gets stubbed vs set.
My guess is the other failures we're seeing is related to something like this.
There was a problem hiding this comment.
Have you checked out the Sinon docs? I believe we’re using it as intended, no “hack” involved.
There was a problem hiding this comment.
I think sinon is not involved here. This should just be setting values on the object here: https://github.com/ttarnowski/ts-sinon/blob/master/src/index.ts#L67. Maybe Proxy in WebKit has slightly different behavior? Maybe a bug since this only shows up in certain cases (e.g. run only this test is fine, but run two versions of this test fails).
There was a problem hiding this comment.
Yeah, it’s really weird because we don’t reuse the stubbed instances between the tests that I can see 🤔
There was a problem hiding this comment.
@maschad did you figure out what the issue was here around Proxy?
There was a problem hiding this comment.
@MarcoPolo I don't think the issue was related to Proxy but rather the peer id fixtures, the relay server behaved as if it was creating reservations for peers that seemed to be reconnecting due to the tests reusing peer ids, we resolved this in this PR
|
@maschad CI is still failing in webkit fyi |
Thanks @MarcoPolo I actually created an issue as I don't believe this failure is unique to our webkit tests. It seems like #1781 is currently blocking CI, will debug. |
|
Is this test more likely to fail on WebKit? Can we handle the flaky test separately (maybe skip for now) and merge WebKit tests now? It would be good to make sure we don't break WebKit from now on, and it would be useful for WebRTC testing. |
It seems to fail consistently on Webkit based on the last few job runs.
Good suggestion, I pushed a commit with a skip for now. |
|
If it fails consistently on WebKit, it doesn't sound like a flaky test to me. Does it fail locally when you run this on a linux box? |
Good suggestion for the linux vm, it wasn't failing on my local macos. It does fail consistently on linux with a stream reset error, but only when ran with the entire suite as opposed to when run in isolation or in it's own test block suite i.e. |
|
@MarcoPolo it turns out the nodes were not shutting down properly in some identify service tests. @achingbrain I do notice that the said tests addressed in a78db93 intentionally close before the connection is established, but that results in this error in the logs. WebSocket connection to 'ws://127.0.0.1:15001/p2p/12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5' failed: WebSocket is closed before the connection is established.it's not too noisy but perhaps we should supress this? Closes #1781 |
That's a bit weird - the |
That's a good point @achingbrain could it be that the |
This fails on linux. Works on MacOS. I haven't investigated why we fail on linux, but it does block us testing webkit as part of the multidim-inderop tester.