types/netmap, ipn/ipnlocal, control/controlclient: rename NodeMutationAdd to NodeMutationUpsert

NodeMutationAdd was a misleading name: a PeersChanged entry in a
MapResponse can represent either a truly new peer or a full
replacement for an existing peer that couldn't be expressed as a
PeerChangedPatch. Calling it "Add" implied it was always a completely
new node, which is wrong.  (I'd changed my mind on the design of
mapping add/delete events to NodeMutations halfway through #19607 and
forgot to update the name, even though I'd updated half the docs)

Rename it to NodeMutationUpsert to reflect the actual semantics: the
node should be inserted or replaced in the peer map regardless of
whether it already existed.

Updates #19607
Updates #12542

Change-Id: Iebd3daddb3318cba02e115a1b184fcb3ee8f83d6
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This commit is contained in:
Brad Fitzpatrick
2026-05-27 08:37:14 -07:00
committed by Brad Fitzpatrick
parent a8f40a2ca5
commit 2c965ab540
6 changed files with 42 additions and 38 deletions
+3 -3
View File
@@ -228,9 +228,9 @@ type NetmapUpdater interface {
// rather than just full updates.
type NetmapDeltaUpdater interface {
// UpdateNetmapDelta is called with discrete changes to the network map.
// The mutation slice may contain [netmap.NodeMutationAdd] and
// [netmap.NodeMutationRemove] entries when peers were added or removed,
// alongside per-field patches.
// The mutation slice may contain [netmap.NodeMutationUpsert] entries when
// peers are inserted or replaced, and [netmap.NodeMutationRemove] entries
// when peers are removed, alongside per-field patches.
//
// The ok result is whether the implementation was able to apply the
// mutations. It might return false if its internal state doesn't