You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Add ClockSnapshot() (time.Duration, time.Time) to ntp.SyncTimer.
Returns offset + lastSync under a single RLock so the polling code
can publish them as a coherent pair. The previous two-call read had
a microseconds-wide window where a sync could land between the two
getter calls and mix offset/timestamp across two sync passes --
vanishingly improbable but cleaner to remove entirely.
- Guard uint64(ts.Unix()) against negative seconds. A pre-1970 RTC
after a successful sync would otherwise wrap to ~1.8e19 and silently
defeat any time()-value>threshold stale-sync alarm. Now publishes 0.
- Rewrite the misleading "float64 round-trip" comment on SetInt64Value.
The float64 conversion exists in cmd/connector/provider, not in the
/node/metrics writer (statusHandler/statusMetricsProvider.go), which
formats stored int64/uint64 directly with %v. Real reason for
SetInt64Value is that uint64 cannot represent negative offsets.
Tests:
- ntp/syncTime_test.go: TestClockSnapshotReturnsConsistentPair asserts
the snapshot matches individual getters post-sync.
- cmd/node/metrics/clockMetrics_test.go:
TestBuildClockMetricsPollingFunc_UsesAtomicSnapshot fails the test
if the polling code falls back to the legacy getters.
TestBuildClockMetricsPollingFunc_NegativeUnixGuard verifies a 1969
timestamp publishes 0, not the uint64 wrap-around.
Addresses review threads from @copilot and @coderabbitai on PR #60.
0 commit comments