Task · TSO-0129

Reject coordination timings that client-go cannot run

Description

Configuration validation currently accepts renew_deadline values greater than retry_period, but the pinned client-go leader elector requires renew_deadline to exceed retry_period multiplied by its 1.2 jitter factor. A configuration such as 15s, 11s, 10s passes config validation and then fails during coordinator construction, turning a recoverable configuration error into a runtime startup failure.

Acceptance Criteria

Definition of Done

Implementation Plan

  1. Add focused failing boundary tests in config and coordination. 2. Align both validation layers with the pinned client-go 1.2 retry jitter requirement and keep existing ordering diagnostics clear. 3. Run focused tests, CodeRabbit, the full gate, and exact-head CI.

Implementation Notes

Wave 10 coordination audit found the mismatch at internal/config/validate.go and internal/coordination/coordination.go: repository validation only requires renew_deadline > retry_period, while client-go v0.37.0 rejects renew_deadline <= 1.2 * retry_period.

Red proof: the focused config and coordinator tests both failed because the 12s renew deadline with a 10s retry period was accepted. Green proof: both layers now reject equality with the client-go 1.2 jitter bound and accept 12s plus 1ns; focused tests passed. CodeRabbit completed over all four changed internal files with zero findings. just check passed at commit 0e212ab5. The pre-commit hook regenerated the affected metrics and root config-schema families and found both already up to date.

Final Summary

Aligned configuration and coordinator validation with client-go JitterFactor 1.2 so invalid election timings fail early with an actionable error. Boundary tests prove equality is rejected and the nearest representable duration above it is accepted; review and the full gate pass.

View the source file on GitHub