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

Investigate RangeError [ERR_SOCKET_BAD_PORT]: Port should be >= 0 and < 65536. Received type number (NaN) within firefox system-tests #30352

Open
AtofStryker opened this issue Oct 3, 2024 · 5 comments · May be fixed by #30393
Assignees
Labels
browser: firefox process: flaky test Related to test(s) that have flake in our internal tests type: chore Work is required w/ no deliverable to end user

Comments

@AtofStryker
Copy link
Contributor

Current behavior

Currently, sometimes in CI after the merging of #30250, firefox fails to start with the error RangeError [ERR_SOCKET_BAD_PORT]: Port should be >= 0 and < 65536. Received type number (NaN). It looks like we are failing to parse the cdp port here. we should wrap this logic and handle the error to see what moz:debuggerAddress capability returns within our system-tests to see if we can fix the error or handle it more gracefully.

Below is a screenshot of the error, which can be seen in this job

Desired behavior

Once we see where the error is coming from, we can either resolve it completely or handle it more gracefully

Test code to reproduce

N/A

Cypress Version

N/A

Node version

N/A

Operating System

N/A

Debug Logs

No response

Other

No response

@AtofStryker AtofStryker self-assigned this Oct 3, 2024
@jennifer-shehane jennifer-shehane added type: chore Work is required w/ no deliverable to end user process: tests Related to our internal tests process: flaky test Related to test(s) that have flake in our internal tests and removed process: tests Related to our internal tests labels Oct 3, 2024
@AtofStryker
Copy link
Contributor Author

I am seeing this still on the #30324, so this is something we need to handle. Its difficult to reproduce, but we can likely handle the issue in the case a CDP address is undefined and send a retry event to relaunch the browser. We send the capability, but it does not get set

Image

@AtofStryker
Copy link
Contributor Author

@whimboo any idea why this would happen? It seems very seldom, but sometimes when sending the moz:debuggerAddress the capability address comes back as undefined. I put together a work around in #30393 but overall seems odd.

@whimboo
Copy link

whimboo commented Oct 15, 2024

@AtofStryker would you mind running tests with the Firefox preference remote.log.level set to Trace? See our documentation for more details. It might indicate what's wrong. Only from the above output I cannot tell anything and I'm also not aware of such a problem on our side. It's basically new to me. Thanks.

@AtofStryker
Copy link
Contributor Author

@whimboo I can. I have it enabled in this circleCI run which is this commit. It happens sporadically so I might not be able to reproduce it on first try (also going to be some failures from printing additional logs) but ill see if I can get a run where it fails with this issue.

@whimboo
Copy link

whimboo commented Oct 15, 2024

Yes, understood. Let me know when it happened next and I'll take a look at it. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
browser: firefox process: flaky test Related to test(s) that have flake in our internal tests type: chore Work is required w/ no deliverable to end user
Projects
None yet
3 participants