-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Add support for hub specific IHubProtocols that don't affect other hubs #15177
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
Conversation
@davidfowl We need to get the API for this locked down today or tomorrow! |
src/SignalR/server/StackExchangeRedis/test/DefaultHubMessageSerializerTests.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer one RedisProtocol ctor if possible
@Pilchie for 3.1 approval. This is fixing the Scaleout + Blazor + SignalR scenario. There is one public API change, we're adding a new constructor to the RedisHubLifetimeManager so we can inject some services from DI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved - thanks
One thing to clarify is that users are not expected to construct this object. It is initialized in DI. We should have (and may in a future major release) made it an |
d9e202c
to
6df502e
Compare
Has this fix been released in 3.1.100? |
It should be in the 3.1.0 runtime. The version you linked is an SDK version but as long as you're using that SDK and targeting |
Thanks! It's strange that I'm still getting this issue then. Going to try and make a min repo. |
Yep, please do and file a new bug if you're still seeing the issue. |
Turns out it's an issue with |
|
Fixes #15128
Might add some more tests later.