Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix message ports not being closed when proxy is relased #6

Merged
merged 3 commits into from
Jan 13, 2025

Conversation

achim-k
Copy link

@achim-k achim-k commented Jan 7, 2025

Changelog

Fix message ports not being closed when proxy is relased

Docs

None

Description

Fixes a regression introduced #3 that caused the

requestResponseMessage(ep, pendingListeners || new Map(), {
    type: MessageType.RELEASE,
  })

promise to never settle which in turn prevented the endpoint from being closed.

src/comlink.ts Outdated Show resolved Hide resolved
src/comlink.ts Outdated Show resolved Hide resolved
@@ -486,8 +487,7 @@ function createProxy<T>(
}
propProxyCache.clear();
unregisterProxy(proxy);
releaseEndpoint(ep);
pendingListeners.clear();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the issue that clearing the listeners here is premature because the releaseEndpoint call needs to access the listeners to resolve? If that's the case it looks like releaseEndpoint itself returns a promise so you could do a .finally(() => pendingListeners.clear()) here instead of passing it to releaseEndpoint?

Or is it important to pass pendingListeners so it can be passed to requestResponseMessage ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or is it important to pass pendingListeners so it can be passed to requestResponseMessage ?

Yes, that's the important bit. If pendingListeners are not passed, the resolver function is not found and the requestResponseMessage promise will never settle.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So why do we allow pendingListeners to be undefined? In what situation is that ok?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was necessary when releasing the endpoint when the proxy is garbage collected. However, thinking about this more, we should also have access to the pendingListeners map as it is tightly coupled to the endpoint now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added a commit that changes the endpoint and pendingListeners to be passed around in a single object (EndpointWithPendingListeners). There is probably a better name for that type/object...

Copy link

@defunctzombie defunctzombie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why it is ok for pendingListeners to be false if we need it to invoke releaseEndpoint correctly - some comments on expected behaviors and implementation details would go a long way towards making this easier to maintain

@achim-k achim-k requested a review from defunctzombie January 8, 2025 20:39
proxy: object,
epWithPendingListeners: EndpointWithPendingListeners
) {
const newCount = (proxyCounter.get(epWithPendingListeners) || 0) + 1;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const newCount = (proxyCounter.get(epWithPendingListeners) || 0) + 1;
const newCount = (proxyCounter.get(epWithPendingListeners) ?? 0) + 1;

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm leaving this as is as the logical OR operator works with much older browser versions. The nullish coalescing operator was introduced much later.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw - that is handled during the transpilation step of ts -> js. When you specify a specific ES version as the target it will produce the code for that ES version so you can write your ts using modern styles.

@achim-k achim-k merged commit 96f643b into main Jan 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants