Communication between 4.3.0 and 4.3.1 fails
See original GitHub issueI’m using comlink with iframes and I’m seeing communication between frames fails when the parent app is running v4.3.1 and the child app is running 4.3.0. Specifically the promise returned from this line never seems to resolve:
// child app
wrap(windowEndpoint(window.parent, window, targetOrigin)).callParentMethod();
This is a major issue for us because the two different frames are separate apps maintained by different teams and have different release schedules so it impractical for us to coordinate a comlink upgrade. For now we are pinning our versions to 4.3.0
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (1 by maintainers)
Top Results From Across the Web
Mule Runtime 4.3.0 Release Notes
Applications that depend on a domain to load resources no longer fail with a "Couldn't find resource: neither on classpath or in file...
Read more >With Mule runtime 4.3.0 we are facing below issue while ...
Facing below error with Mule Runtime Version 4.3.0-20210319 While deploying the application in to couldhud,But same application Working fine ...
Read more >VMware SD-WAN 4.3.1 Release Notes
4.3.0. 4.3.1. 4.3.1. 4.3.0. 4.3.1. 4.5.0. 4.3.1. 4.3.0. 4.3.1 ... As a result the communication between the Orchestrator and the Edge no longer...
Read more >Cumulus Linux 4.3 Release Notes
Issue ID Description Affects Fi...
3163845 4.3.1‑4.4.5
2902013 The NCLU commit command adds a five second delay. 4.2.1‑4.4.5
2893895. CM‑33315 4.0.0‑4.3.1 4...
Read more >Tesira release notes
would fail to send a configuration when using more than 64 channels of AVB. 4.3.0. Release Date: August 2022. Software Download Link: Download ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Definitely not, some people already upgraded to it and it works fine. Unpublishing will break those apps/libs.
I can think of only 2 possible options here:
I’m personally OK with the 1st option here since I already spent some time updating things 😄
If you change the protocol then it’s a breaking change, regardless if the public API is unchanged.
I remember when a minor version upgrade of Comlink broke my app (the shape of the error object was changed), so I pinned Comlink to its minor version. Now a patch version upgrade broke my app, so now I have to pin Comlink to a specific version.
I don’t think Comlink makes it clear enough that you must use compatible versions of Comlink in all of your frames. Compatible here meaning, basically the same exact version. With the way comlink is versioned - protocol changes introduced in minor/patch versions - it’s too easy to break production.