Blazor (server-side) System.InvalidOperationException: Received a notification for a rendered batch when not expecting it.

[marcelgoldstein]

I`ve got an Blazor server-side app deployed as self-contained (dotnet 3.0 preview4) on Azure AppServices.
It seems to run fine on simple Pages (counter with additional buttons or the weather forecast displayed in an pageable datagrid), but it dies after 0-5 UI interactions on a more advanced page.
In the browser-console the following error occurs and after that error the signalR connection is disconnected (without the automatic reconnection kicking in):

On my local dev maschine no such error occured even once.

To see this error happening open this link to the deployed webApp and click on some button or dropdowns, after some UI interactions the error should occur in the browser console.

If needed the source code for this app is located here.

Same error as reported in this comments:
https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-core-3-0-preview-4/#comments-367

[redowl3]

Have you got WebSockets enabled?

[marcelgoldstein]

thx @redowl3, after enabling it on the Azure AppService under "AppServiceXY -> Configuration -> General settings -> Web sockets" it looks good!

But why was it functioning on simple pages when Web sockets are disabled? I would expect an error on the first connect rather than dying mid-session.

[redowl3]

I think it handles the initial couple of requests fine but soon runs into trouble, on your local machine running under IIS websockets is enabled by default.

[SteveSandersonMS]

@anurse I'm just guessing here, but is it possible that when SignalR falls back to a non-WebSockets transport, that message delivery order is no longer guaranteed? We are relying on delivery order guarantees.

[BrennanConroy]

Looks like a dupe of #9875
And they are repro-ing it with WebSockets in some cases.

[analogrelay]

but is it possible that when SignalR falls back to a non-WebSockets transport, that message delivery order is no longer guaranteed

Message delivery order is not guaranteed in general, but should be preserved if you are sending all the messages from the same server to a single client (i.e. you aren't doing broadcasting to groups or users or all clients). I believe Blazor fits in that scenario. Having said that, we should probably have a conversation about your message ordering needs because it's not generally something we've "guaranteed". Most of the time we tell our users that if strict ordering is essential, they should add sequencing logic to their messages. I think you're OK in the way you're using it, but we should make sure we understand the expectation.

Since you're using MessagePack, we fall back from WebSockets straight to Long Polling (since Server-Sent Events can't handle non-text data without encoding). Long Polling does have a potential ordering problem since clients are making multiple requests. In theory, a client could make a second poll request while we're in the middle of writing out some messages to the first poll, which would cause havoc for message ordering. This can happen in our client if the client things the poll times out but the server has actually sent a message (it just got lost). When the client opens a second poll, the server thinks it has sent some messages so those messages are dropped. Ordering should preserved, but there can be dropped messages.

[davidfowl]

Hmm, if ordering isnt preserved over a single connection then we have some bugs. The way everything is designed, things should be received and sent in order.

[analogrelay]

Hmm, if ordering isnt preserved over a single connection then we have some bugs.

I should rephrase, ordering is preserved. However, messages may be lost and we wouldn't terminate the connection, so it's not "strict" ordering (in the TCP sense).