Don't silently reattach a share to a different process after port reuse - #5
Open
AadhilFarhan wants to merge 1 commit into
Open
Don't silently reattach a share to a different process after port reuse#5AadhilFarhan wants to merge 1 commit into
AadhilFarhan wants to merge 1 commit into
Conversation
shares/relays were keyed by port only. If a shared process died and a different, unrelated process bound the same port before the next 3s poll's cleanup ran, the stale relay/direct-share entry survived (the cleanup check was just "is this port still live") and kept exposing whatever now occupied that port — a process the user never chose to share, with the row's "sharing" badge silently reattaching to it. Now tracks the pid a share was started for (sharedPIDs, covering both the relayed and direct-URL cases) and tears the share down whenever the port's live occupant no longer matches, not just when the port goes fully quiet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
shares/relayswere keyed by port only. The review flagged this scenario: a shared process dies, and a different, unrelated process binds the same port before the next 3-second poll's cleanup runs — the old cleanup check was just "is this port still live," which is still true, so the stale relay/share survived and kept exposing whatever now occupies that port. The row's "sharing" badge silently reattaches to a process the user never opted to share.Fix
Added
sharedPIDs: [Int: Int32], recorded at share time for both the relayed and direct-URL (allInterfaces) cases. The cleanup pass inrefresh()now tears a share down whenever the port's live occupant no longer matches the pid it was originally shared for — not only when the port goes fully quiet.While in this code I also noticed the original cleanup loop only ever iterated
relays, so a direct (non-relayed,allInterfaces) share'sshares[port]entry was never cleaned up at all when that server died — no relay existed to trigger the loop. Folded that into the same fix since it's the same cleanup logic and the same class of bug (stale share state), rather than opening a fourth PR for one adjacent line.Test plan
AppModelisn't covered by the existing test suite, consistent with the rest of the UI/state layer in this codebase; the actual timing race requires driving the live UI against real process churn on a real port within a 3s window, which isn't something I can automate in this session).