fix: WebSocket readyState should not revert from CLOSED to CLOSING

[mcollina]

Summary

• Fixes WebSocket readyState incorrectly reverting from CLOSED (3) to CLOSING (2) after close event fires
• Uses queueMicrotask() to defer onSocketClose() call, ensuring close event fires after state transition completes
• Adds guard to prevent duplicate onSocketClose() calls

Test plan

• Added test case for issue WebSocket transitions back from CLOSED to CLOSING #4742
• All 89 WebSocket tests pass
• WPT close-connecting test now passes (was failing with "assert_unreached")
• WPT close-connecting-async test passes

Fixes: #4742

[codecov-commenter]

Codecov Report

❌ Patch coverage is 81.81818% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.26%. Comparing base (761fce9) to head (e8ba25f).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/web/websocket/websocket.js	75.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4752      +/-   ##
==========================================
+ Coverage   93.22%   93.26%   +0.03%     
==========================================
  Files         109      109              
  Lines       34024    34010      -14     
==========================================
- Hits        31720    31718       -2     
+ Misses       2304     2292      -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KhafraDev]

#4745 (comment)

[mcollina]

@KhafraDev that does not link directly to anything on my machine.

[KhafraDev]

Not sure why, this is what I was linking to (domenic's comment):

I'm concerned this fix isn't quite following the spec. It adds some extra state transition guards and a microtask. Whereas, the proper per-spec fix would be to add a real task (not microtask) at a higher level. E.g. instead of a microtask just for the handler.onSocketClose() part of failWebsocketConnection, the entirety establishWebSocketConnection, closeWebSocketConnection, and whatever undici's equivalent of "when a WebSocket message has been received" is.

I suspect if that sort of fix is implemented, then no specific state transition patches will be necessary, since the state transitions will always be queued properly in the task queue.

[mcollina]

I'm not convinced by that argument, unless needed by the spec.

The problem is that adding macroticks everywhere will necessarily slow things down and increase memory consumption.

cc @domenic

[domenic]

It is needed by the spec? The spec is very explicit!