You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The @effectionx/worker channel implementation relies on once(channel.port1, "close") to detect when the responder crashes or closes. However, browser MessagePort does NOT have a close event - this is a Node.js worker_threads feature only.
Current Behavior
In Node.js: Works correctly, close event fires when port is disconnected
In browsers: The close path in the race never resolves, leaving crash detection entirely dependent on the optional timeout
Without a timeout specified, the operation will hang indefinitely if the responder crashes in a browser environment
Relevant Code
worker/channel.ts around line 211:
// Race response vs close (detects responder crash)constresult=yield*race([waitForResponse(),closeDetection(),// Uses once(port, 'close') - browser doesn't support this]);
Suggested Solutions
Option A: Document & Require Timeout for Browsers
Add JSDoc warning that browser usage requires timeout
Consider throwing an error if no timeout is provided in browser environments
Simplest fix, documents the limitation
Option B: Implement Heartbeat/Keepalive Protocol
Send periodic ping messages from caller
Expect pong/keepalive ACKs from responder
Treat missed pings as crash detection
More robust but more complex
Option C: Feature Detection
Detect if running in Node.js vs browser at runtime
Use different crash detection strategies based on environment
Could combine with Options A or B
References
MDN MessagePort.close(): No close event documented
Node.js worker_threads docs: close event is Node.js specific
whatwg/html issue #1766: Long-standing request for close event in browsers
Electron adds its own close event extension (not web-standard)
Problem
The
@effectionx/workerchannel implementation relies ononce(channel.port1, "close")to detect when the responder crashes or closes. However, browserMessagePortdoes NOT have acloseevent - this is a Node.jsworker_threadsfeature only.Current Behavior
closeevent fires when port is disconnectedRelevant Code
worker/channel.tsaround line 211:Suggested Solutions
Option A: Document & Require Timeout for Browsers
Option B: Implement Heartbeat/Keepalive Protocol
Option C: Feature Detection
References
MessagePort.close(): No close event documentedworker_threadsdocs:closeevent is Node.js specificcloseevent extension (not web-standard)Related