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(ws): fix incorrect host pattern on messages #12321

Merged

Conversation

KrisAphalon
Copy link
Contributor

function call was missing the second argument

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

What is the current behavior?

Currently, when using platform-ws and calling host.switchToWs().getPattern() on ArgumentsHost given in exception filter, we don't get a pattern but we get a data object. For example for following message on the websocket:

{
    event: 'foo',
    data: {  test: 1  }
}

we would get { test: 1 } as a "pattern"

Issue Number: N/A

What is the new behavior?

When using platform-ws and calling host.switchToWs().getPattern() on ArgumentsHost given in exception filter we get correct pattern matched for this branch. For the following message on the websocket:

{
    event: 'foo',
    data: {  test: 1  }
}

we correctly get 'foo' as a pattern

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

If I traced the code correctly, currect behaviour happens because the code always gets the last item from the list as a pattern, but on platform-ws the message.event was never added to that list.

I'm not yet fluent with writing for libraries of this size and I didn't see any tests for platform-ws or for platform-socket.io. That's why I didn't add a test myself. I did see there were some tests for getPattern(), but none of them caught this problem. Probably because they were more high-level than the change here.

function call was missing the second argument
@coveralls
Copy link

Pull Request Test Coverage Report for Build 01d7bc0e-3eb7-47ff-ab0e-8865252cdc2d

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 92.61%

Totals Coverage Status
Change from base Build ac9c1c51-3db3-4328-86ea-d3cf5d1cde0c: 0.0%
Covered Lines: 6466
Relevant Lines: 6982

💛 - Coveralls

@kamilmysliwiec
Copy link
Member

Could you please provide a minimum reproduction repository (Git repository/StackBlitz/CodeSandbox project)?

@KrisAphalon
Copy link
Contributor Author

Right. I think this is sufficient: https://github.com/KrisAphalon/nestjs-incorrect-host-pattern-example
Not sure if it can cut more corners with it. The gist of it is I throw exception in a method in a gateway (or in real code in some service called within it) and the custom WebsocketExceptionFilter catches it. Within the filter I call host.switchToWs().getPattern() and get an incorrect variable.

@kamilmysliwiec
Copy link
Member

cc @jmcdo29 (added in #10545)

Copy link
Member

@jmcdo29 jmcdo29 left a comment

Choose a reason for hiding this comment

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

Nice catch. I can confirm with my external library that there was indeed a bug with this, and the proposed changes do fix it

@kamilmysliwiec kamilmysliwiec merged commit 2d13d08 into nestjs:master Sep 1, 2023
3 checks passed
@kamilmysliwiec
Copy link
Member

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants