fix: send wake request to tunnel on system wake#262
Draft
EhabY wants to merge 5 commits into
Draft
Conversation
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
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.
After macOS sleep/wake, Coder Connect can stay unusable for minutes when no link-change event fires, leaving path re-discovery to the periodic re-STUN timer (coder/coder#26736).
The daemon-side hook merged in coder/coder#26739 (
WakeRequest/WakeResponse, tunnel protocol1.3). This PR makes Coder Desktop emit it:IORegisterForSystemPowerand reacts only tokIOMessageSystemHasPoweredOn, which is delivered on full wake only, never on dark wake.Speakernow advertises protocol1.3and records the negotiated version.WakeRequestover the existing tunnel RPC channel, gated on negotiated version>= 1.3so older daemons are never sent a message they don't understand. Failures are logged; nothing is torn down.vpn.protosynced with the wake messages andvpn.pb.swiftregenerated with protoc-gen-swift 1.28.2 (matching the pinned SwiftProtobuf version).Why IOKit instead of
NSWorkspace.didWakeNotification?The helper is a root LaunchDaemon with no GUI login session, and
NSWorkspacenotifications are only delivered to processes inside one (apps/LaunchAgents). IOKit power notifications are delivered to daemons, andkIOMessageSystemHasPoweredOnhas the same full-wake-only semantics asdidWakeNotification(https://developer.apple.com/forums/thread/770517). Since the helper owns the tunnel lifecycle, the wake kick works even when the menu-bar app isn't running.Tests
ProtoVersioncomparison (Comparable).Speaker.wake()round-trip over an in-memory pipe.Speaker.wake()is a no-op against a 1.1 peer.Decision log
Speaker.handshake()previously discarded the negotiated version; it now stores it. The wake RPC lives in aSpeakerextension typed to the manager role so the gate is unit-testable; logging happens inManager.wake()like the other RPCs.WakeResponse.success: kept in the proto for wire parity with upstream, but not read by the client.StartProgressmessages, both of which would add noise. Generated bindings are additive only.Closes #260
Generated by Coder Agents on behalf of @EhabY.