[BUG]: Crypto streaming client connect never finishes

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When using ALPACA_ENV.GetAlpacaCryptoStreamingClient(alpacaKey).ConnectAndAuthenticateAsync(); the connection never completes.

Expected Behavior

Connection should complete.

Steps To Reproduce

I added a class to UsageExamples and ran it:

using System;
using System.Threading.Tasks;
using Alpaca.Markets;

namespace UsageExamples
{
    internal class CryptoStreaming
    {
        private const string API_KEY = "REPLACEME";
        private const string API_SECRET = "REPLACEME";
        private static readonly IEnvironment ALPACA_ENV = Environments.Paper;
        
        public async Task Run()
        {
            var alpacaKey = new SecretKey(API_KEY, API_SECRET);
            using var cryptoStreamingClient = ALPACA_ENV.GetAlpacaCryptoStreamingClient(alpacaKey);
            cryptoStreamingClient.Connected += status =>
            {
                Console.WriteLine($"Crypto streaming client connected and authorized: {status == AuthStatus.Authorized}");
            };
            cryptoStreamingClient.OnError += exception =>
            {
                Console.WriteLine($"Crypto streaming error: {exception}");
            };
            cryptoStreamingClient.OnWarning += warning =>
            {
                Console.WriteLine($"Crypto streaming warning: {warning}");
            };
            cryptoStreamingClient.SocketOpened += () =>
            {
                Console.WriteLine("Crypto streaming socket opened");
            };
            cryptoStreamingClient.SocketClosed += () =>
            {
                Console.WriteLine("Crypto streaming socket closed");
            };
            await cryptoStreamingClient.ConnectAndAuthenticateAsync();
        }
    }
}

The console only ever writes 2 lines: the socket opened and then after a few seconds the socket closed.

Environment

This occurs on 2 of my dev environments:

- SDK Version: latest v5 and latest v6 preview
- OS (version, bitness): Windows 11 x64, Ubuntu 20.04 x64
- .NET SDK (version): 6.0.101 (win11) and 6.0.201 (ubuntu)
- target process .NET version/bitness: 6 x64

Anything else?

In WebSocketTransport second check for WebSocketMessageType.Close here I added these 3 lines to debug why it was closing “normally” without reporting anything:

var read = await transport.Input.ReadAsync().ConfigureAwait(false);
var inputSoFar = Encoding.UTF8.GetString(read.Buffer.ToArray());
Trace.TraceInformation("message type close");

inputSoFar = [{"T":"success","msg":"connected"}][{"T":"error","code":404,"msg":"auth timeout"}]

This led me to believe the first “connected” message wasn’t being received correctly. I commented out the 0-byte read here and then the connection works.

This connection was working on Friday and the other streaming client ALPACA_ENV.GetAlpacaStreamingClient(alpacaKey) connection still works without the code modification described above. I wonder if maybe something changed in the crypto streaming endpoint that affects the 0 byte read?

[natehitze]

I tested it last night and it was working as expected. Thanks for the quick release!

[natehitze]

I’ve gathered some more information by logging on receive. The 0 byte read is [Text-1] and the following read is [Text-2]:

Crypto streaming socket opened 2022-03-27T21:06:58.3654326Z [Text-1] read 0 bytes. Is End? False 2022-03-27T21:06:58.3671037Z [Text-2] read 1 bytes. Is End? False [ 2022-03-27T21:06:58.3691621Z [Text-1] read 0 bytes. Is End? False 2022-03-27T21:06:58.3691815Z [Text-2] read 33 bytes. Is End? False {“T”:“success”,“msg”:“connected”} 2022-03-27T21:06:58.3692302Z [Text-1] read 0 bytes. Is End? False 2022-03-27T21:06:58.3692350Z [Text-2] read 1 bytes. Is End? False ] 2022-03-27T21:06:58.3692557Z [Text-1] read 0 bytes. Is End? True 2022-03-27T21:07:08.3918579Z [Text-2] read 1 bytes. Is End? False [ 2022-03-27T21:07:08.3920233Z [Text-1] read 0 bytes. Is End? False 2022-03-27T21:07:08.3920426Z [Text-2] read 45 bytes. Is End? False {“T”:“error”,“code”:404,“msg”:“auth timeout”} 2022-03-27T21:07:08.3920877Z [Text-1] read 0 bytes. Is End? False 2022-03-27T21:07:08.3920942Z [Text-2] read 1 bytes. Is End? False ] 2022-03-27T21:07:08.3921217Z [Text-1] read 0 bytes. Is End? True 2022-03-27T21:07:08.3926531Z [Close-2] read 0 bytes. Is End? True Crypto streaming socket closed

In the bolded line you can see a 0-byte read has EndOfMessage=true but then a 10 second delay until the 2nd receive call starts receiving the auth timeout message.The client could solve this issue by either removing the 0-byte read (which is how it works on <= netstandard2.0) or handling its EndOfMessage instead of calling a 2nd read.