The clock reference was inferred from the correction being nonzero, which
inverts the warning. base::unixtime::update() returns without applying a
shift smaller than kIgnoreTimeDifference, three seconds - so a machine whose
clock is right keeps a zero shift and looks exactly like one that never heard
from a server. The HTTP correction does not cover for it either: the Date
fetch runs only off a fake TLS failure path, so a client that works never
performs one.
Put together, clock_ref=none would have been logged on every hello of every
healthy user, and stayed silent for the users already off by the three
seconds a relay refuses. A warning everyone sees stops being read, and the
first thing to stop being read is the one case it exists for.
So the flag now records the event it was always meant to record: a server
time arrived. It is raised at all four places one can arrive - three in
receive.cpp, one in the key creator - next to the update call rather than
inside it, because the update is exactly what may decide to do nothing. The
flag lives in the runtime layer as process-wide atomic state; base::unixtime
would be the natural home, but it is a submodule, and its own ValueUpdated
has the same hole on the ignore path.
The guard test now pins both halves: that the reference comes from
ServerTimeReceived(), and that every update call site has a matching mark.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
958d05339b