[SignalR] Cannot use InvokeAsync While there is an stream ongoing in SignalR

[SLjavad]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

i have an stream from client to server using SignalR.
stream channel closes and completes when i invoke a client method from server and server program does not continue from InvokeAsync line.

this is server side streaming code that reads the stream channel :

public async Task ReplayFromAdminToServer(ChannelReader<int> replay)
{
    try
    {
        while (await replay.WaitToReadAsync())
        {
            while (replay.TryRead(out var item))
            {
                Console.WriteLine(item);
            }
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine("EXCEPTION");
        Console.WriteLine(ex.Message);
    }

    Console.WriteLine("END OF ReplayFromAdminToServer");
}

and this is a server method that invokes a client method:

public async Task<bool> StreamHandshake(string data)
{
    if (data == "stream_handshake")
    {
        try
        {
            var token = new CancellationTokenSource();
            var res = await Clients.Caller.InvokeAsync<bool>("stream_handshake", "some-data", token.Token);
            return true;
        }
        catch (Exception ex)
        {
            Console.WriteLine("EX in StreamHandshake");
            Console.WriteLine(ex.Message);
            return false;
        }
    }
    return false;
}

the program will not continue from the line await Clients.Caller.InvokeAsync<bool>("stream_handshake", "some-data", token.Token); and my stream closes suddenly

Expected Behavior

streaming and invoking a client method are two separate actions.
so Invoking shouldn't affect streaming.
streaming should be continued and server can invoke any method of client it wants.
These are two different actions and have nothing to do with each other.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

7.0.100

Anything else?

No response

[BrennanConroy]

Please provide a minimal repro project as a github repository.

[ghost]

Hi @SLjavad. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[SLjavad]

hi @BrennanConroy

https://github.com/SLjavad/SignalRStreamTest

i have provided this repo for testing.

run SignalRClientTestUi and SignalRServerTest
on winform app :

1. start
2. click on Send Stream to start streaming
3. then click on Send Request to call StreamHandshake method on server.

as you can see stream closes after clicking on Send Request

[BrennanConroy]

Thanks for the repro, I had tried to repro with the javascript app, but because of how the issue occurs it would have taken an extra step to occur with the javascript client.

The problem is that the server generated InvocationID conflicts with the client generated StreamID, so an invocation result can complete a stream accidentally

aspnetcore/src/SignalR/server/Core/src/Internal/DefaultHubDispatcher.cs

Line 174 in f58f954

if (connection.StreamTracker.TryComplete(completionMessage))

If using the Redis backplane this can't occur because we generate a random ID every invocation instead of an incrementing number that starts at 0.

aspnetcore/src/SignalR/server/StackExchangeRedis/src/RedisHubLifetimeManager.cs

Line 816 in f58f954

private static string GenerateInvocationId()

We might want to switch to this method for the in-memory implementation too so that collisions can't occur with streams.

[SLjavad]

Thanks , it worked using Redis backplane.
But Can you explain more ? how can it conflicts ? as the log shows , StreamId is 1 and InvocationId is 2.

[BrennanConroy]

It's not the hub method invocation ID (2 in your logs), it's the ID generated by the server that waits for a client response, since you're using client results. So if you didn't use client results, you couldn't hit this issue.

[SLjavad]

ah .. got it .. you're right , thanks for clarifying

[davidfowl]

Do we need to patch this?

[BrennanConroy]

Yep