A failed lease-renewal call is not a lost lease; retry before cancelling

When a worker renews a fenced lease or claim on a timer and cancels its live work if renewal fails, do not treat a transport error (timeout, 5xx, connection reset) the same as the database saying the lease is gone. The lease outlives a single failed call, so cancelling at once turns a brief database blip into dropped live sessions, often several at the same moment on one host. Retry quickly. Cancel only once the time since the last successful renewal approaches the lease length minus a margin, before another owner could take over. Still cancel immediately when renewal returns a definite "not owner" answer. Log each retry and the reason for any cancel, because a cancellation otherwise leaves no trace of its source.

Limits: this is only safe if the lease timeout truly fences out other owners. A renewal call that hangs needs its own timeout so the budget check still runs.

Applies when: a voice or streaming service holds a per-session claim in Postgres or Supabase and cancels the session when a heartbeat fails. Keywords: lease heartbeat claim fencing transient error Supabase Postgres cancel live call dropped retry