intermittent callback/channel issues in Safari 16

I apologize upfront for the somewhat low quality of this bug report. It is a very hard bug to reproduce outside of our particular app (which is a big, heavy, app). And, even then, it’s non-deterministic, so a reduced repro isn’t going to be of much value. The bug isn’t in comlink, but I think there is a potential mitigation within comlink. Also, having this issue documented may help others.

On Safari 16.0, the basic callback pattern described here will sometimes silently stop working.

https://github.com/GoogleChromeLabs/comlink/tree/main/docs/examples/02-callback-example

Meaning, the callback may work for awhile, but at some point the callback function stops being called on the Main thread. This happens for callbacks with and without parameters passed in. Once it stops working, it never starts working again.

I traced into comlink and found that the postMessage from the Worker is successfully executed, but the addEventListener('message', ...) associated with the MessageChannel callback port is never invoked on the Main thread. There’s no messageerror callback on main, either.

I believe what’s happening is that Safari is inappropriately garbage collecting the MessageChannel under certain conditions. Things like memory pressure appear to play a role. Retaining the Endpoint created by the proxyTransferHandler and subscribed to in expose by pushing it into a module scoped data structure thus far appears to completely mitigate the problem for us.

It looks like Safari has had some issue in this space reported before: https://bugs.webkit.org/show_bug.cgi?id=193184 https://bugs.webkit.org/show_bug.cgi?id=184502

[dmarini]

@twmillett we are having the exact same issue in our application and I’d like to understand more about the mitigation that you have employed. We ended up using a straight postMessage/onMessage communication pattern to replace our callbacks that stopped working. We suspected we needed to strengthen the referential integrity of something but failed to identify the right object to operate with (tried the callback and the proxy itself).

Is the workaround you used to replace the comlink internal proxyTransferHandler in the transferhandlers collection with one that can store the “port1” reference created by MessageChannel()? Thanks in advance for any advice you can give.

[dmarini]

@twmillett this is great thank you, I’ll look into this if our current fix candidate continues to demonstrate the issue!