RC1 Failed connection handshake after update from Preview 7 -> RC1

[caliberdigitalllc]

Hi all,

I just updated my blazor applications to RC1 as well as all other nugets that were preview 7 -> RC1, and am now getting this on all of my blazor apps. My MVC apps are working fine after the update, but all 4 of my updated blazor apps are doing this. Should I revert back to Preview 7? Pretty blocked here.

Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionManager: Debug: New connection JKAjyXbT2EB55U85XkOndA created.
Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionDispatcher: Debug: Sending negotiation response.
Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionDispatcher: Debug: Establishing new connection.
Microsoft.AspNetCore.SignalR.HubConnectionHandler: Debug: OnConnectedAsync started.
Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport: Debug: Socket opened using Sub-Protocol: '(null)'.
Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport: Debug: Waiting for the application to finish sending data.
Microsoft.AspNetCore.SignalR.HubConnectionContext: Debug: Failed connection handshake.
Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport: Debug: Socket closed.
Microsoft.AspNetCore.Http.Connections.Internal.HttpConnectionManager: Debug: Removing connection RyCTYkvlKdR_KNL529goQg from the list of connections.

[caliberdigitalllc]

Update: here's what's in the chrome dev tools console at the time of the failure:
blazor.server.js:1 [2021-09-17T19:20:46.863Z] Error: WebSocket is not in the OPEN state
log @ blazor.server.js:1
blazor.server.js:1 [2021-09-17T19:20:46.863Z] Error: Failed to start the circuit.

Again, all I did was update from Preview 7 to RC1 with no other code changes.

[BrennanConroy]

Could you capture a network trace https://docs.microsoft.com/aspnet/core/signalr/diagnostics?view=aspnetcore-5.0#network-traces

Just confirming, this looks like this is server-side blazor?
What did preview7 look like in your logs?

[caliberdigitalllc]

I've attached both the RC1 session and the Preview 7 session to this message @BrennanConroy

Sessions.zip

[caliberdigitalllc]

And yes, this is Blazor Server.

[BrennanConroy]

Huh, the preview7 trace doesn't seem to contain any info. If you know how to use Wireshark I actually prefer that over Fiddler for websocket connections.

What I'm trying to figure out is if your preview7 app was falling back to longpolling, but as of RC1 blazor no longer allows that fallback by default #34644 so if you were having issues connecting to websockets before it might have been silently falling back.

How are you hosting your app? Can you confirm that websockets was working in preview7?

[caliberdigitalllc]

@BrennanConroy Let me try and get better logs. If it helps, here is the front end for the Preview 7 app (hosted on IIS) http://app.frdb.bscapps.ca - it does redirect to identity server quickly, but perhaps you can get the logs you need from it when it loads.

[caliberdigitalllc]

FWIW, I did add the code suggested in the breaking change update for long polling and that didn't fix the issue on RC1.

[BrennanConroy]

http://app.frdb.bscapps.ca - it does redirect to identity server quickly, but perhaps you can get the logs you need from it when it loads.

Ok, that one is using websockets successfully.

I'm not able to repro the issue locally when running RC1.

Let me try and get better logs

Yes please.

[caliberdigitalllc]

@BrennanConroy I went ahead and updated our Preview 7 staging site to the local code RC1 code that was failing -> https://app.frdb.bscapps.ca/

Same error now on the URL you were able to review above.

[caliberdigitalllc]

However, if you actually click "login" you'll see you're redirected to the identity server (MVC Core RC1) just fine, and the login form works fine (calls the .net core APIs, etc). If I log in, the Blazor Rc1 app loads, but indeed I keep getting the same socket not open error within the app itself.

[BrennanConroy]

Dug into this a little, and the issue seems to be related to someone replacing the browser websocket implementation so that the WebSocket.OPEN constant is now a function instead of the value 1.

Searching the js files from your site I can see that vendors.min.js from BscTheme is overriding the websocket implementation incorrectly which is likely causing the issues. Is this a file of yours?

[caliberdigitalllc]

@BrennanConroy yeah, it's just the static files in a shared razor library for our 4 applications (common CSS, common HTML, etc) - Nothing in there has changed in forever. I wonder if one of the theme JS files is now conflicting with something that changed in RC1? Are you able to tell me what JS to hunt for in the library that I can see if that's the case?

[BrennanConroy]

I can only see the minified file, but the code looks like

if (null != M && L.ajax.trackWebSockets) {
	window.WebSocket = function(e, t) {
		var i;
		return i = null != t ? new M(e,t) : new M(e),
		R("socket") && n.trigger("request", {
			type: "socket",
			url: e,
			protocols: t,
			request: i
		}),
		i
	}
	;
	try {
		x(window.WebSocket, M)
	} catch (e) {}

And it looks like it's the x(window.WebSocket, M) function call that sets a bunch of properties on the new websocket implementation.

[caliberdigitalllc]

pace.min.zip
vendors.min.zip

I did a search for "websocket" in the theme files, and the 2 attached JS files showed matches. Vendors.js is loaded by the theme we purchased to drive the dashboard widgets and whatnot.

We've been using this theme for a year and only RC1 is what broke it - super interesting.

Can you suggest what code change needs to be made to the JS to fix this? Do I just comment out the noted JS above? I'm not at all a JS guy.

[caliberdigitalllc]

Quick update: I commented out the reference to vendors.js, and the site works now (though the HTML theme itself is now completely broken without that Js loading) - so:

1. Why did RC1 suddenly make this JS cause the whole app to break when it's been fine for many months?
2. What can I do in that vendors.js to make the site not break but the rest of the JS to still load?

[BrennanConroy]

1. Why did RC1 suddenly make this JS cause the whole app to break when it's been fine for many months?

No idea, we haven't changed anything in SignalR in this area between preview7 and RC1, and blazor changes are very unlikely to have affected anything here either. In any case, this is a bug in your vendor package and should be brought to them.

2\. What can I do in that vendors.js to make the site not break but the rest of the JS to still load?

There is a trackWebSockets property in the vendors.js file and if you can set that to false before it replaces the websocket then your site will start working and still have the other functionality working.

[caliberdigitalllc]

Thanks @BrennanConroy for all the support. I'll report the bug and this thread to the theme provider. In the meantime I've commented out the trackWebsockets pieces and all is well now.

[caliberdigitalllc]

For anyone else that comes along to this thread, the theme in question is FREST by Pixinvent (https://www.pixinvent.com/demo/frest-clean-bootstrap-admin-dashboard-template/landing-page/), so the RC1 fix is to unminify vendors.js, and comment out the trackWebsockets references, and Blazor will start working again.