Feature request: reliable way to send SignalR messages on shutdown

[kjkrum]

My web app runs background tasks that prevent IIS from gracefully shutting down until they complete. (This works well; code here.) The tasks poll IApplicationLifetime.ApplicationStopping.IsCancellationRequested in their innermost loops and try to send cancellation messages to SignalR clients when shutdown is detected. But SignalR has usually disconnected the clients before the tasks get a chance to notify them.

I don't know enough about the framework to suggest a solution.

[halter73]

The problem seems to be that SignalR starts closing the connection as soon as ApplicationStopping fires. It might be interesting to have something like BeforeApplicationStopping that could be "blocked" with a task for users to send messages to clients. @Tratcher

[Tratcher]

BeforeBeforeBefore* 😁 That way lies madness.

Hmm, StopApplication is the very first signal from Host.StopAsync.
https://github.com/aspnet/Extensions/blob/7005708d7a26e5f6ed4bcb0271f052241033b8a6/src/Hosting/Hosting/src/Internal/Host.cs#L62-L71

The problem seems to be that SignalR starts closing the connection as soon as ApplicationStopping fires.

What if SignalR notified the app before it started closing connections?

[kjkrum]

Compare IRegisteredObject.Stop from Framework (Q&A about usage). It seems that cancelling IApplicationLifetime.ApplicationStopping is analogous to calling Stop(true), or at least SignalR treats it that way. Maybe IApplicationLifetime could expose two tokens analogous to Stop(false) and Stop(true).

Edit: Wait, it already does. So perhaps SignalR could simply disconnect on ApplicationStopped instead of ApplicationStopping.

https://github.com/aspnet/AspNetCore/blob/04c3192d3cec396a9f2343fb5407d6777349b9df/src/SignalR/common/Http.Connections/src/Internal/HttpConnectionManager.cs#L49

[halter73]

@kjkrum The problem with having SignalR wait for ApplicationStopped to disconnect is that by the point ApplicationStopped fires, the server should have already aborted every connection. AFAIK ApplicationStopping is SignalR's last chance to gracefully close its connections.

Having SignalR fire its own event from its ApplicationStopping handler prior to it closing its connections like @Tratcher suggested should give SignalR app developers the hook they need to send a final message before server shutdown.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[BrennanConroy]

Dupe of #25069