Skip to content
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

Merged
merged 21 commits into from
Jun 6, 2023
Merged

Conversation

MarcoPolo
Copy link
Collaborator

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.

@MarcoPolo MarcoPolo changed the title Add webkit test script feat: Add webkit test script Mar 16, 2023
@MarcoPolo
Copy link
Collaborator Author

Are we not using protocol/.github#487 in this repo?

@achingbrain
Copy link
Member

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

@achingbrain
Copy link
Member

From the CI error it looks like the job just needs to install some extra deps?

╔══════════════════════════════════════════════════════╗
║ Host system is missing dependencies to run browsers. ║
║ Please install them with the following command:      ║
║                                                      ║
║     sudo npx playwright install-deps                 ║
║                                                      ║
║ Alternatively, use apt:                              ║
║     sudo apt-get install libvpx7\                    ║
║         libevent-2.1-7\                              ║
║         libopus0\                                    ║
║         libwoff1\                                    ║
║         libharfbuzz-icu0\                            ║
║         libgstreamer-plugins-base1.0-0\              ║
║         libgstreamer-gl1.0-0\                        ║
║         libhyphen0\                                  ║
║         libmanette-0.2-0\                            ║
║         libgles2\                                    ║
║         gstreamer1.0-libav                           ║
║                                                      ║
║ <3 Playwright Team                                   ║
╚══════════════════════════════════════════════════════╝]

@achingbrain
Copy link
Member

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 check job which'll be faster.

@MarcoPolo
Copy link
Collaborator Author

From the CI error it looks like the job just needs to install some extra deps?

Not the actual error. Just the error in CI. This has failed on me on a linux with the correct deps installed.

@MarcoPolo MarcoPolo force-pushed the marco/js-libp2p-test-webkit branch 2 times, most recently from a9e5026 to 5a00304 Compare March 20, 2023 21:24
@MarcoPolo
Copy link
Collaborator Author

MarcoPolo commented Mar 24, 2023

The failure is when we do something like this:

await crypto.subtle.deriveKey(
    { "name": "PBKDF2", "salt": new Uint8Array(16), "iterations": 32767, "hash": { "name": "SHA-256" } },
    await crypto.subtle.importKey('raw', new Uint8Array(), { "name": "PBKDF2" }, false, ['deriveKey', 'deriveBits']),
    { name: "AES-GCM", length: 128 }, true, ['encrypt'])

here: https://github.com/libp2p/js-libp2p-crypto/blob/e7bb8b26655af7d0d8a7387a2923c6c3929952fe/src/ciphers/aes-gcm.browser.ts#L35

@MarcoPolo
Copy link
Collaborator Author

MarcoPolo commented Mar 24, 2023

Possibly related: https://bugs.webkit.org/show_bug.cgi?id=169468#c1

I'm guessing these are failing because there is no PBKDF2 implementation on GTK, and that once someone hooks it up things will start working.

Edit, nvm it seems like that has been done.

@MarcoPolo
Copy link
Collaborator Author

Aha! it turns out webkit+linux doesn't like it when you import a key with no bytes.

e.g. this works:

await crypto.subtle.deriveKey(
    { "name": "PBKDF2", "salt": new Uint8Array(16), "iterations": 32767, "hash": { "name": "SHA-256" } },
    await crypto.subtle.importKey('raw', new Uint8Array(1), { "name": "PBKDF2" }, false, ['deriveKey', 'deriveBits']),
    { name: "AES-GCM", length: 128 }, true, ['encrypt'])

Confusingly, this error happens when you try to use the imported key with deriveKey rather than when you importKey.

@MarcoPolo
Copy link
Collaborator Author

This is blocked on libp2p/js-libp2p-crypto#319

@maschad maschad self-assigned this May 9, 2023
@MarcoPolo MarcoPolo changed the title feat: Add webkit test script test: Add webkit test script May 18, 2023
src/autonat/index.ts Outdated Show resolved Hide resolved
src/autonat/index.ts Outdated Show resolved Hide resolved
stream.sink.returns(Promise.resolve())

// stub autonat protocol stream
const stream = stubObject<Stream>({
Copy link
Member

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.

Copy link
Collaborator Author

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.

Copy link
Member

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.

Copy link
Collaborator Author

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).

Copy link
Member

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 🤔

Copy link
Collaborator Author

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?

Copy link
Member

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 maschad requested a review from achingbrain May 23, 2023 02:16
@MarcoPolo
Copy link
Collaborator Author

@maschad CI is still failing in webkit fyi

@maschad
Copy link
Member

maschad commented May 31, 2023

@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.

@MarcoPolo
Copy link
Collaborator Author

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.

@maschad
Copy link
Member

maschad commented May 31, 2023

Is this test more likely to fail on WebKit?

It seems to fail consistently on Webkit based on the last few job runs.

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.

Good suggestion, I pushed a commit with a skip for now.

@MarcoPolo
Copy link
Collaborator Author

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?

@maschad
Copy link
Member

maschad commented May 31, 2023

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. libp2p.upgrader. I suspect there is a socket which is not being closed in the previous tests which is causing this... investigating...

@maschad
Copy link
Member

maschad commented Jun 1, 2023

@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

@achingbrain
Copy link
Member

@MarcoPolo it turns out the nodes were not shutting down properly in some identify service tests.

That's a bit weird - the libp2p node is shut down in the afterEach for those tests.

@maschad
Copy link
Member

maschad commented Jun 1, 2023

That's a bit weird - the libp2p node is shut down in the afterEach for those tests.

That's a good point @achingbrain could it be that the afterEach is called after the failing test is run in some sort of race condition ? Either way I am not sure if this related directly to this PR but seems to be a testing environment issue where our tests hang from time to time

@achingbrain achingbrain merged commit 14aa40f into master Jun 6, 2023
@achingbrain achingbrain deleted the marco/js-libp2p-test-webkit branch June 6, 2023 10:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants