Browser MessagePort does not emit 'close' event - crash detection relies on Node.js-only feature

Problem

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)
const result = 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)

Related

• Discovered via CodeRabbit review on PR #138

Start in worker/channel.ts around line 211 and compare the race's close-detection behavior with the browser and Node.js MessagePort APIs referenced in the issue. Determine which proposed browser strategy the project should adopt; done means browser crash or disconnect handling no longer hangs indefinitely without an undocumented assumption about timeouts.