SignalR client-to-server streaming method on Hub not recognized as streaming unless return type contains stream parameter

[blue-shoes]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I am developing an application that will accept a stream from a Raspberry Pi client using a golang implementation of SignalR (github.com/philippseith/signalr) and consume it in an ASP.NET Core web app. Per the documentation here,

A hub method automatically becomes a client-to-server streaming hub method when it accepts one or more objects of type ChannelReader or IAsyncEnumerable.

Unless I am misunderstanding this statement, a hub method with the following signature should be recognized as a streaming method:

public async Task ReceiveStream(IAsyncEnumerable<string> data)

However, when I attempt to push a stream from the golang client, the connection is unsuccessful, and SignalR provides the following message back to the client:

Error:\"The client attempted to invoke the non-streaming 'ReceiveStream' method with a streaming invocation.\"

If I instead set the hub method signature to:

public async Task<IAsyncEnumerable> ReceiveStream(IAsyncEnumerable<string> data)

and provide an unused return IAsyncEnumerable object, streaming from the client works exactly as expected.

Searching the code base for the specific error message returned to the client turns up the DefaultHubDIspatcher.ValidateInvocationMode method, which appears to be failing the invocation on this test:

if (!hubMethodDescriptor.IsStreamResponse && isStreamResponse)

We can see here from the original (non-working) method signature that this hub method does not have a stream response, hence the failure at this check. There appears to be no check that the hub method descriptor has Stream Parameters, which should also indicate the the method is a streaming method, per the documentation.

Expected Behavior

A hub method with a non-streaming return type but with streaming parameters should be recognized as a streaming method by the hub dispatcher in the DefaultHubDispatcher.ValidateInvocationMode checks.

Steps To Reproduce

Minimal reproducable example here: https://github.com/blue-shoes/SignalR-Stream-Issue

Exceptions (if any)

No response

.NET Version

No response

Anything else?

Run in Visual Studio Professional 2022 LTSC 17.0.0.

dotnet --info output:

[davidfowl]

There are streaming parameters and streaming results. This method public async Task ReceiveStream(IAsyncEnumerable<string> data) is a normal invocation with a streaming parameter. It's possible the golang client doesn't support that? (it's not part of your repo so I can't see what it's doing).

[blue-shoes]

The git repo contains the go client in the "go" directory.

I do not think this is an issue on the Go side, as the error message states that the client is using a streaming invocation on a non-streaming method.

[davidfowl]

Do me a favor and try to invoke this method from the C# client. You cannot use the Stream methods because there's no return stream, but you can use InvokeAsync with a streaming parameter.

[BrennanConroy]

Taking a quick glance at the go library, it looks like it doesn't properly support upload streaming.

The library always sends a StreamInvocation when pushing streams to the server even though that should only be used when the hub method returns a stream.

[blue-shoes]

@davidfowl , I was able to successfully invoke the method from the JS client, which for posterity I have committed to the MRE repository listed above. Based on this, I think Brennan is likely correct that the issue lies in the go library and not in SignalR. Thank you for your assistance.

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.