Skip to content

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

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

Closed
AtofStryker opened this issue Oct 3, 2024 · 8 comments · 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!

@whimboo
Copy link

whimboo commented Oct 21, 2024

@AtofStryker did this issue actually happen on specific platforms only? Maybe there is some more data to localize the issue?

@AtofStryker
Copy link
Contributor Author

@AtofStryker did this issue actually happen on specific platforms only? Maybe there is some more data to localize the issue?

I think so far I've only seen it on linux but there is a larger sample size there. Still working on getting a reproduction in a Circle run.

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Oct 24, 2024

Released in 13.15.1.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v13.15.1, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Oct 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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