[ws] Fix debugging web socket JS code + add test

[ilonatommy]

Follow up for #96618. The test tries to resemble the actions from demo as much as possible. The goal is to reproduce

blazor.web.js:1crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
Unhandled exception rendering component: System.Net.WebSockets.WebSocketException (0x80004005)
at System.Net.WebSockets.BrowserWebSocket.ConvertResponse()
at System.Net.WebSockets.BrowserWebSocket.ReceiveAsyncCore(ArraySegment`1 buffer, CancellationToken cancellationToken) at BlazorApp1.Client.Pages.Test.ReceiveData()
 in BlazorWasmWebsocketDemo\BlazorWasmWebsocketDemo\BlazorApp1\BlazorApp1.Client\Pages\Test.razor:line 42 at BlazorApp1.Client.Pages.Test.StartTest()
 in BlazorWasmWebsocketDemo\BlazorWasmWebsocketDemo\BlazorApp1\BlazorApp1.Client\Pages\Test.razor:line 23
  at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)
  at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)

Observed when debugging: receive and send+close WS are launched nearly at the same time and we enter "ws_wasm_receive" with empty event buffer (no on_message event were recorded previously) but also with WS state as "closed" (so obviously the "send" action was already triggered but did not get recorded by the browser).

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Follow up for #96618.

Author:	ilonatommy
Assignees:	ilonatommy
Labels:	area-System.Net
Milestone:	-

[pavelsavara]

This is the tricky part. What would happen if the wait was not there at all ?

[ilonatommy]

We would have sent one after another, so it would be event order:

• connect, ask for receive 1, send1, send2, ask for receive 2.

Adding this delay we are on the boarder of the above scenario and the below:

• connect, ask for receive 1, send1, ask for receive 2, send 2.

By "on the boarder" I mean it's random, sometimes we fall into 1st scenario, sometimes into the 2nd.

[pavelsavara]

ask for receive 2 should have no impact on the JS side order of WS events and JS side buffering, right ?

[pavelsavara]

Are we trying to get into situation that "ws.state == CLOSE" but the on_message for the second message was not called yet ?

If that's possible, the current implementation is wrong. But I need to see it before I can believe it 🔍

[ilonatommy]

The time when we ask for receive seems important, when using the debugger, we enter the receiving method before we got "on_message_sent" event but after the WS is closed. That's why I was trying to time it as close in time to closing and sending actions as possible.

[pavelsavara]

Anyway, we could try to stop using ws.state for this and rely on the on_close event

[ilonatommy]

Removing the if (readyState == WebSocket.CLOSED) block of code from ws_wasm_receive eliminates the exception during debugging.

[ilonatommy]

Does it mean that

     const readyState = ws.readyState;
     if (readyState == WebSocket.CLOSED) {
         const receive_status_ptr = ws[wasm_ws_receive_status_ptr];
         setI32(receive_status_ptr, 0); // count
         setI32(<any>receive_status_ptr + 4, 2); // type:close
         setI32(<any>receive_status_ptr + 8, 1);// end_of_message: true
         return resolvedPromise();
     }

is redundant? Managed code does no need setting these bits?

[pavelsavara]

That's good question. on_close has similar code and would deliver the resolution if we deleted this.

[ilonatommy]

There is a difference between the demo and the tests: demo does not close the socket, only dispose of it and in case the socket was opened without using CloseAsync(), the WebSocket connection will be abruptly terminated. This termination will occur without following the WebSocket protocol's normal closure handshake, potentially leading to unexpected behavior or errors on the client side. Upon correcting the demo code to close the socket (like our tests do), I cannot reproduce the issue with "lost messages". The current, working version of code has the if (readyState == WebSocket.CLOSED) block removed.