fix(signer): retain keygen retries across temporary policy lookup failures

ZlyDevMayarequested to merge
zly/keygen-retry-retention into develop

Problem

A temporary THORNode API failure while scheduling or firing a keygen retry can permanently discard the retry. An unavailable policy response is not evidence that retries were disabled or that the ceremony expired.

Changes

  • Retain retry intent when Mimir or height lookups fail, and recheck on the existing block cadence.
  • Treat a THORNode height behind the delivered keygen height as inconclusive rather than terminal.
  • Revalidate retry policy and the ceremony validity window before execution.
  • Deduplicate waiting workers and protect successor retries from stale-worker cleanup.
  • Retry only the failed keygen request, preserving its original block for shared validity-window semantics.
  • Track retry workers during signer shutdown.
  • Add independent Asgard fixtures that assert actual TSS execution, including the selected ceremony and participant set.

Scope and compatibility

This is a Common Bifrost change extracted from S00 (!5026 (merged)), based directly on develop.

Tests cover normal delivery, direct invocation, and scheduled retries.

These are whole-ceremony retries, not DKG payload/result transport retries. No scheduler, parallel-vault support, or forced DKG cancellation is added.

Shutdown now waits for owned retry workers, including an attempt already executing. Cancellation of an overlong active DKG remains separate work.

Verification

Verified locally for the extracted implementation committed as 4646b69826:

  • Full mocknet signer package passed.
  • Focused untagged retry tests passed.
  • Repeated race tests passed.
  • Tests cover temporary lookup failures, lagging heights, recovery, disabled/expired policy, duplicate workers, successor ownership, Asgard dispatch, and the unconditional XMR brake.

Merge request reports