-
Notifications
You must be signed in to change notification settings - Fork 445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: Add webkit test script #1627
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maschad did you figure out what the issue was here around Proxy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.