I feel like this kind of logic doesn't belong at this layer, where we're using history to infer what needs to happen next. Very path dependent.

Instead when we make an XPC connection we should explicitly (or implicitly on new connection) request the peer state. It's always the case that we need peer state at start of day.

As the tunnel goes up and down that also needs to be communicated (e.g. the user could stop the VPN via the System Settings).

As the tunnel goes up and down that also needs to be communicated (e.g. the user could stop the VPN via the System Settings).

This functionvpnDidUpdate gets called by theNotificationCentre, syncing it up with the VPN in System Settings. (Subscribing to events retrieves the current state too, so that works on app startup)

Instead when we make an XPC connection we should explicitly (or implicitly on new connection) request the peer state.

An XPC connection is only made when the app attempts to communicate with the NE, so we can't rely on XPC to tell us the NE is already running. (As seen in theNE & XPC example)

It's always the case that we need peer state at start of day.

However, always attempting to retrieve the peer state onCoderVPNService.init works just as well. Though if the NE isn't running, we do create a spurious error log. WDYT?

I think it's fine for us to wait until we know whether the NE is running before we attempt to query the peer state. What I'm worried about is path dependence in the state machine: if we later add more states, or more transitions, you could end up in the.connected state in a way that does require us to query the peer state, but we haven't transitioned directly from thedisabled state.

Could we just always request a peer state update when we get to.connected? That way we have some belief that the NE is running, so if we can't get it, it's a legit error. I realize in the case where we are starting the VPN up we'll request a spurious update, but are the updates idempotent?

Yeah, the first update sent when the VPN starts will be identical to the one we manually request - but the one requested will overwrite the other if it arrives after. I'll have it always request on.connected.

Actually, this is causing the NE to crash.vpnDidUpdate gets called when other parts of the VPN configuration change, not just the status, so the.connected branch was running multiple times on startup. The XPC was going through to the NE fine, but It looks like the speaker or the dylib can't keep up with multiple peer state requests in quick succession - We'll need to investigate that at some point, but not now.

Doesn't this clear call make handling thedeletedAgents anddeletedWorkspaces inapplyPeerUpdate unnecessary since there won't be any workspaces or agents left?

update.deletedAgents andupdate.deletedWorkspaces will always be empty on agetPeerState response, yeah. The Go code already keeps track of all known agents & workspaces, so as Dean suggested I think it'd be good to just send the full current state to the NE on any update.