question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Communication between 4.3.0 and 4.3.1 fails

See original GitHub issue

I’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:open
  • Created 2 years ago
  • Comments:7 (1 by maintainers)

github_iconTop GitHub Comments

2reactions
maksnestercommented, Jun 1, 2021

Unpublish 4.3.1?

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:

  1. Do nothing. Make people sad but force them to update everything to the latest version.
  2. Publish 4.3.2 with revert to make those apps affected by 4.3.1 work again (once updated). Go for 5.0 with breaking changes. Yeah, API remained the same, but does it matter if apps are broken after the update?

I’m personally OK with the 1st option here since I already spent some time updating things 😄

1reaction
guanzocommented, Jun 8, 2021

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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found