Nullability in SignalR by BrennanConroy · Pull Request #29219 · dotnet/aspnetcore

BrennanConroy · 2021-01-11T21:43:59Z

BrennanConroy · 2021-01-11T21:46:49Z

        /// Gets the user for this connection.
        /// </summary>
-        public virtual ClaimsPrincipal? User => Features.Get<IConnectionUserFeature>()?.User;
+        public virtual ClaimsPrincipal User => Features.Get<IConnectionUserFeature>()?.User ?? new ClaimsPrincipal();


Not sure what to do here. Cache the User?

The reason I'm not keeping it null is because it's nicer to deal with an empty ClaimsPrincipal than a null one. An empty one will not be authenticated in any way or have any claims. The Auth types we use don't have null annotations for the user as the expectation is that you'll at least pass an empty one.

Assign blank ClaimsPrincipal to underlying IConnectionUserFeature when the property is accessed?

The IConnectionUserFeature could come from anyone (in theory), and the interface allows a null user. Plus the interface itself could not be on the connection.

JamesNK · 2021-01-21T23:50:56Z

Will review when PR is out of draft 🥇

pranavkm · 2021-01-22T00:05:10Z

        /// </returns>
        [SuppressMessage("ApiDesign", "RS0026:Do not add multiple overloads with optional parameters", Justification = "Required to maintain compatibility")]
-        public static Task<TResult> InvokeAsync<TResult>(this HubConnection hubConnection, string methodName, object arg1, CancellationToken cancellationToken = default)
+        public static Task<TResult> InvokeAsync<TResult>(this HubConnection hubConnection, string methodName, object? arg1, CancellationToken cancellationToken = default)


Should these be Task<TResult?>

I don't think so? That would force callers to always handle null even if they never expect it to be null. If they use a nullable for TResult then that means they expect a null value and should handle it, and the compiler will let them know that. So seems better to let the user decide.

Fair enough. It's effectively the same choice we made with JSInterop. But we also do not provide any guarantees against it which is crummy.

pranavkm · 2021-01-22T00:10:35Z

            }

-            return reader.GetString();
+            return reader.GetString()!;


Now that's just a lie

No it isn't, we check above that the token type is a string. If the string is null it would have token type null.

JamesNK · 2021-01-22T23:22:14Z

            return hubConnection.On(methodName,
                new[] { typeof(T1), typeof(T2), typeof(T3) },
-                args => handler((T1)args[0], (T2)args[1], (T3)args[2]));
+                args => handler((T1)args[0]!, (T2)args[1]!, (T3)args[2]!));


Hmm, I wonder if there is a better way to avoid all these bangs.

JamesNK · 2021-01-22T23:23:42Z

-        public override string ConnectionId
+        public override string? ConnectionId
        {
+#pragma warning disable CS8764 // Nullability of return type doesn't match overridden member (possibly because of nullability attributes).


Should ConnectionId be made nullable on ConnectionContext?

I really think that people should be able to rely on ConnectionContext.ConnectionId being non-null. I'm thinking this should just throw if someone tries to access this property before StartAsync() completes.

This implementation of ConnectionContext.ConnectionId is already a bit odd in that its setter throws, so I don't think throwing from the getter when the connection hasn't started is a big deal.

people should be able to rely on ConnectionContext.ConnectionId being non-null

It's not just if you access it before starting, if you skip negotiation then this will be null as well.

JamesNK · 2021-01-22T23:41:10Z


        /// <inheritdoc />
-        public override Task SendAllAsync(string methodName, object?[]? args, CancellationToken cancellationToken = default)
+        public override Task SendAllAsync(string methodName, object?[] args, CancellationToken cancellationToken = default)


Is this a change from .NET 5? There is an aspnetcore annoucement issue for nullability changes.

This is an API change, however passing null would have thrown

JamesNK · 2021-01-22T23:41:57Z

+            {
+                if (_user is null)
+                {
+                    _user = Features.Get<IConnectionUserFeature>()?.User ?? new ClaimsPrincipal();


halter73 · 2021-01-27T23:51:09Z

        /// Gets or sets the URL used to send HTTP requests.
        /// </summary>
-        public Uri Url { get; set; }
+        public Uri Url { get; set; } = default!;


var httpConnectionOptions = new HttpConnectionOptions(); var urlString = httpConnectionOptions.Url.ToString();

The above throws, right? If so, I think this should be marked nullable.

I might feel differently if it was super common for developer to call the HttpConnectionOptions.Url getter and in practice it was always set, but I expect most developers just call WithUrl() and never touch this property.

The reason I changed it was because of "! fatigue", everywhere we access this property internally it will be non-null

aspnetcore/src/SignalR/clients/csharp/Http.Connections.Client/src/HttpConnectionFactory.cs

Lines 59 to 61 in e737b6e

if (_httpConnectionOptions.Url != null && _httpConnectionOptions.Url != uriEndPoint.Uri)

{

throw new InvalidOperationException($"If {nameof(HttpConnectionOptions)}.{nameof(HttpConnectionOptions.Url)} was set, it must match the {nameof(UriEndPoint)}.{nameof(UriEndPoint.Uri)} passed to {nameof(ConnectAsync)}.");

I do appreciate trying to avoid "! fatigue" but I don't think that's enough of a reason to misrepresent the nullability of a public property. We could add an internal non-nullable property that mirrors Url and throws if it is null as a sanity check to avoid the fatigue.

We do this in places where something could be null, but for all typical usage it won't be.

e.g. https://github.com/dotnet/aspnetcore/blob/a08aa2dd318956d5b7295561d9423252f6071a52/src/Hosting/Abstractions/src/WebHostBuilderContext.cs

Right, that's why I said this initially:

I might feel differently if it was super common for developer to call the HttpConnectionOptions.Url getter and in practice it was always set, but I expect most developers just call WithUrl() and never touch this property.

I expect most developers just call WithUrl() and never touch this property

Right, that makes it less of an issue if we lie with the API.

I would argue that if it's not a huge issue either way, we should default to no lying with the API.

I'll try out a private member so we can avoid using ! everywhere in HttpConnection then.

BrennanConroy added the area-signalr Includes: SignalR clients and servers label Jan 11, 2021

BrennanConroy commented Jan 11, 2021

View reviewed changes

davidfowl requested review from JamesNK and pranavkm January 20, 2021 05:31

pranavkm reviewed Jan 22, 2021

View reviewed changes

Base automatically changed from master to main January 22, 2021 01:33

BrennanConroy marked this pull request as ready for review January 22, 2021 21:25

BrennanConroy requested review from a team and halter73 as code owners January 22, 2021 21:25

JamesNK reviewed Jan 22, 2021

View reviewed changes

BrennanConroy force-pushed the brecon/nullable branch from 42cdc0c to 5c0693f Compare January 25, 2021 18:29