Tracking issue for the rotation path that #4618 switches off. Referenced from the step 5 comment in zetaclient/tss/setup.go so the constraint has an owner rather than living only in code comments.
What is off
#4618 makes two changes that together mean a scheduled keygen will not run while a finalized TSS exists:
Setup skips KeygenCeremony entirely when GetTSS returns a key.waitForNewKeygen is deleted from TSSListener, which removed the only trigger that restarted zetaclient for a scheduled keygen.
This was deliberate. Restarting on the keygen record is what turned a routine validator unbonding into an outage: the record is reset to "pending at block MaxInt64" on any observer set change, so every signer shut down at once and none could start again.
It was also accepted knowingly — there is no TSS keygen planned in the foreseeable future, and an opt-in escape hatch was judged not worth adding to a hotfix going to two release branches.
How to rotate today
Remove the current TSS first, or reintroduce a deliberate trigger. The step 5 comment in setup.go spells this out so nobody has to rediscover it under pressure.
Also disabled by the same PR
The two start-tss-migration-* e2e suites are turned off in .github/workflows/e2e.yml. They schedule a keygen and wait for it to succeed, which no longer happens, so they would burn their 40 minute timeout on every nightly run. Re-enabling rotation means re-enabling those two matrix rows.
What a fix probably looks like
@morde08 suggested honouring a scheduled keygen when the record still carries grantees and an operator opts in — the grantee check being what distinguishes a real scheduled rotation from the blanked record.
Anyone picking this up should also settle whether the trigger belongs back in TSSListener or somewhere that cannot be confused with the blanking.
Tracking issue for the rotation path that #4618 switches off. Referenced from the step 5 comment in
zetaclient/tss/setup.goso the constraint has an owner rather than living only in code comments.What is off
#4618 makes two changes that together mean a scheduled keygen will not run while a finalized TSS exists:
SetupskipsKeygenCeremonyentirely whenGetTSSreturns a key.waitForNewKeygenis deleted fromTSSListener, which removed the only trigger that restarted zetaclient for a scheduled keygen.This was deliberate. Restarting on the keygen record is what turned a routine validator unbonding into an outage: the record is reset to "pending at block MaxInt64" on any observer set change, so every signer shut down at once and none could start again.
It was also accepted knowingly — there is no TSS keygen planned in the foreseeable future, and an opt-in escape hatch was judged not worth adding to a hotfix going to two release branches.
How to rotate today
Remove the current TSS first, or reintroduce a deliberate trigger. The step 5 comment in
setup.gospells this out so nobody has to rediscover it under pressure.Also disabled by the same PR
The two
start-tss-migration-*e2e suites are turned off in.github/workflows/e2e.yml. They schedule a keygen and wait for it to succeed, which no longer happens, so they would burn their 40 minute timeout on every nightly run. Re-enabling rotation means re-enabling those two matrix rows.What a fix probably looks like
@morde08 suggested honouring a scheduled keygen when the record still carries grantees and an operator opts in — the grantee check being what distinguishes a real scheduled rotation from the blanked record.
Anyone picking this up should also settle whether the trigger belongs back in
TSSListeneror somewhere that cannot be confused with the blanking.