Changing an account setting did not reach a connected peer. The handler spawns
the fan-out with `go` and hands it the HTTP request context, which the server
cancels the moment the handler returns. The goroutine is usually still starting
at that point, so it dies before sending anything, and UpdateAccountPeers'
error is discarded by the caller, so nothing says so in the logs.
Measured against a local deployment, management at trace level: the PUT logs
"updating peers for account <id> from ...UpdateAccountPeers" and then goes
silent, and the peer receives no sync at all. With the context detached, the
same PUT delivers three syncs to the peer within a second, and a peer that was
never restarted picks the new value up.
context.WithoutCancel keeps the values on the context - the request ID, the
account ID, the trace span - so the fan-out still logs under the request that
caused it. It only drops the cancellation. The same pattern is already used two
screens down for the login-expiry and inactivity-expiry jobs, and by
dispatchAffected, which is why the DNS and policy paths fan out correctly today
while the settings path does not.
This affects every field in that trigger list, not just the one this branch
adds. The five sibling spawns in the zones and zone-record managers have the
same defect and are left alone here: different module, not reproduced, and
widening a security branch into them helps nobody.
riccardom
8074614e89