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

chore: remove node-http-proxy and instead install package from npm and patch it #29499

Merged
merged 1 commit into from May 13, 2024

Conversation

AtofStryker
Copy link
Contributor

Additional details

Additionally can close cypress-io/node-http-proxy#1 and #29453 since we will no longer be using the fork. The fork is only one commit ahead of the base release, so it makes more sense on our end to patch the package (with the changes suggested in cypress-io/node-http-proxy#1 as well) so we can more easily maintain changes to the node-http-proxy

Steps to test

How has the user experience changed?

PR Tasks

Comment on lines 17 to 28
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
-and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
-
-Generated by [`auto-changelog`](https://github.com/CookPete/auto-changelog).
-
-## [v1.18.1](https://github.com/http-party/node-http-proxy/compare/1.18.0...v1.18.1) - 2020-05-17
-
-### Merged
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AtofStryker Is this patch supposed to have all of this information in here? I thought it's typically a few lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been trying to figure this out and I think its our friend .yarnclean https://github.com/cypress-io/cypress/blob/develop/.yarnclean#L53. going to turn it off to develop the patch then reenable it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jennifer-shehane it was the yarnclean. should be fixed now

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch

Copy link
Member

@jennifer-shehane jennifer-shehane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AtofStryker Looks like this test is reliably failing across chrome/firefox/webkit

Screenshot 2024-05-09 at 4 02 03 PM

@AtofStryker
Copy link
Contributor Author

@AtofStryker Looks like this test is reliably failing across chrome/firefox/webkit

Screenshot 2024-05-09 at 4 02 03 PM

I wonder if its because I nohoisted the package. looking into it

@AtofStryker AtofStryker force-pushed the chore/update_node_proxy_patch branch 3 times, most recently from 017059b to c1ab750 Compare May 10, 2024 02:16
Copy link

cypress bot commented May 10, 2024

Passing run #55373 ↗︎

0 230 4 0 Flakiness 0

Details:

chore: remove node-http-proxy and instead install package from npm and patch it ...
Project: cypress Commit: 486a9b07ba
Status: Passed Duration: 11:24 💡
Started: May 10, 2024 2:24 PM Ended: May 10, 2024 2:35 PM

Review all test suite changes for PR #29499 ↗︎

@AtofStryker AtofStryker force-pushed the chore/update_node_proxy_patch branch from c1ab750 to 486a9b0 Compare May 10, 2024 13:30
@AtofStryker
Copy link
Contributor Author

@jennifer-shehane turns out the enum doesn't actually exist on the socket object so it was evaluating the expression to false. I have updated the patch to be:

if (!res.upgrade && socket.readyState === "open" && !socket.destroyed)

which should work as expected

proxyReq.on('response', function (res) {
// if upgrade event isn't going to happen, close the socket
- if (!res.upgrade) {
+ if (!res.upgrade && socket.readyState === "open" && !socket.destroyed) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AtofStryker Is this case sensitive? Would be a bit ridiculous if it is, but they are in all caps in the docs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which docs are you referring to? Are you saying the readyState is in caps?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is a Websocket that conforms to MDN standards, WebSocket.readyState is a number that corresponds to WebSocket.OPEN, etc. It looks like socket-io also conforms to this. What's creating this socket, and what type is it? The stream() method here isn't called directly by http-proxy, so it must be getting called from packages/server, or as an internal node lifecycle type process.

readyState also doesn't seem to be a property on duplex streams, which is what a node http/https socket is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, socket is implied to be a duplex stream (I believe) in checkMethodAndHeader with the use of .destroy(), which is a member of Duplex but is not a member of WebSocket... what the heck is this value? 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logging the value of socket here during the websockets_spec system test, and it looks like a decorated Duplex stream - it has stream related properties, like destroyed, _readableState, and _writeableState, but it also has properties describing a server:

{
   ...restOfProperties,
   server: {
     ...somePrivateProps,
     allowHalfOpen: boolean
     connectionsCheckingInterval: number
     headersTimeout: number
     highWaterMark: number
     ...etc
   }
 }

It does not, however, have a readyState property, so I'm not certain this conditional will ever evaluate as true.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to log the value of socket.readyState directly. It's not enumerable and it returns undefined for Object.getOwnPropertyDescriptor(socket, 'readyState') but when accessed directly:

console.log('readyState is enumerable:', socket.propertyIsEnumerable('readyState'));
// => readyState is enumerable: false

console.log('description:', Object.getOwnPropertyDescriptor(socket, 'readyState'));
// => description: undefined

console.log('socket.readyState', typeof socket.readyState, socket.readyState);
// => socket.readyState string open

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like this is the Socket.readyState property

@AtofStryker AtofStryker merged commit 9ce6f3f into develop May 13, 2024
81 of 82 checks passed
@AtofStryker AtofStryker deleted the chore/update_node_proxy_patch branch May 13, 2024 15:43
@cypress-bot
Copy link
Contributor

cypress-bot bot commented May 21, 2024

Released in 13.10.0.

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

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators May 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cypress crashes with "Error: This socket has been ended by the other party" at unpredictable times
4 participants