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

fix: upgrader should not need muxers #517

Merged
merged 3 commits into from
Dec 16, 2019

Conversation

vasco-santos
Copy link
Member

With the current codebase, having a streamMuxer is mandatory, which was not the case before. This PR allows a connection to be upgraded just with crypto.

Note: the connection properties regarding multiplexers are throwing an error now.

])

expect(connections).to.have.length(2)
})
Copy link
Member Author

Choose a reason for hiding this comment

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

Should I test the errors with multiplexer operations in the connection?

Copy link
Contributor

Choose a reason for hiding this comment

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

It might be good to add a quick test. They should also throw errors with codes.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be good to also add a test for closing. It's going to the MultiaddrConn so it should be fine, but I think having it for avoid regressions in the future would be good.

Copy link
Member Author

Choose a reason for hiding this comment

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

I added to this test. I think it is better than create a new test

@vasco-santos vasco-santos force-pushed the fix/upgrader-should-not-need-muxers branch from 45c2760 to 8d7c110 Compare December 13, 2019 14:24
src/upgrader.js Outdated Show resolved Hide resolved
])

expect(connections).to.have.length(2)
})
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be good to add a quick test. They should also throw errors with codes.

Copy link
Contributor

@jacobheun jacobheun left a comment

Choose a reason for hiding this comment

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

Just some minor things, otherwise this looks good!

@@ -244,20 +292,9 @@ class Upgrader {
}

// Pipe all data through the muxer
pipe(muxedConnection, muxer, muxedConnection)
pipe(upgradedConn, muxer, upgradedConn)

maConn.timeline.upgraded = Date.now()
Copy link
Contributor

Choose a reason for hiding this comment

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

We should just set this right after we created the timeline Proxy, that way we don't need to set it here and in the !Muxer if statement above.

src/upgrader.js Outdated Show resolved Hide resolved
])

expect(connections).to.have.length(2)
})
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be good to also add a test for closing. It's going to the MultiaddrConn so it should be fine, but I think having it for avoid regressions in the future would be good.

Co-Authored-By: Jacob Heun <jacobheun@gmail.com>
Copy link
Contributor

@jacobheun jacobheun left a comment

Choose a reason for hiding this comment

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

🎉

@jacobheun jacobheun merged commit 56a1825 into refactor/async-await Dec 16, 2019
@jacobheun jacobheun deleted the fix/upgrader-should-not-need-muxers branch December 16, 2019 11:26
jacobheun added a commit that referenced this pull request Jan 24, 2020
* fix: upgrader should not need muxers

* chore: address review

* chore: apply suggestions from code review

Co-Authored-By: Jacob Heun <jacobheun@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants