Bedrock.ControlPlane.Director.Recovery.RecoveryPhase behaviour (bedrock v0.5.2)

View Source

Behavior for recovery phases in the Bedrock recovery process.

All recovery phases should implement this behavior to ensure consistent interfaces and access to necessary context data.

Summary

Callbacks

Execute the recovery phase with the given recovery attempt and context.

Types

context()

@type context() :: %{
  cluster_config: Bedrock.ControlPlane.Config.t(),
  old_transaction_system_layout:
    Bedrock.ControlPlane.Config.TransactionSystemLayout.t(),
  node_capabilities: %{required(Bedrock.Cluster.capability()) => [node()]},
  lock_token: binary(),
  available_services: %{required(String.t()) => {atom(), {atom(), node()}}},
  coordinator: pid()
}

Callbacks

execute(t, context)

Execute the recovery phase with the given recovery attempt and context.

The context provides access to Director state that phases need but shouldn't be stored in the recovery attempt itself.

Returns:

  • {updated_recovery_attempt, next_phase_module} - Normal transition to next phase
  • {updated_recovery_attempt, :completed} - Terminal state, recovery complete
  • updated_recovery_attempt - Legacy terminal state for backward compatibility
  • {recovery_attempt, {:stalled, reason}} - Phase cannot proceed, will retry
  • {recovery_attempt, :newer_epoch_exists} - Director superseded, halt immediately

Stall vs Error Handling: Stall conditions indicate temporary issues (insufficient resources, service unavailability) where recovery should retry. Error conditions like :newer_epoch_exists indicate permanent failures requiring immediate halt.