Retry the final key TTL after a failover

[amankrx]

What and why

Follow-up to #2688. @corcillo asked for the reconnect-and-retry on both
EXPIRE calls; only the temp-key one got it and I mistakenly reported both as
done. The final-key EXPIRE still failed outright on a transient failover,
while every other step in update reconnects and retries once.

Same change routes it through ttl_seconds(), so the clamp to at least one
second now covers both sites rather than just the temp key. Not reachable
today since config rejects zero, but it was meant to be defence in depth at
both.

Also corrected the comment above it, which still described the pre-review
design where only the final key carried a TTL.

How this was verified

Added update_retries_the_ttl_after_a_failover: the mock returns a connection
reset on the first EXPIRE of the real key and succeeds on the retry. It
fails with the retry arm removed, with the error the reviewer predicted:

Error { code: Unavailable, messages: ["Io: connection reset by peer",
  "While setting TTL on 3031...30-2 in RedisStore::update()"] }

Full store suite (30 binaries) and clippy are clean.

Risk

Low. One more round trip only on a failover that would previously have failed
the write.

The retry is bounded to a single attempt, matching the rename directly above
it, so a persistently unreachable master still surfaces an error rather than
looping.

---

This change is 

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
nativelink	Ready	Preview	Aug 14, 2026 5:20am
nativelink-aidm	Ready	Preview	Aug 14, 2026 5:20am