Erlang y Elixir: gen_statem, la máquina como ciudadano de primera

Las tres lecciones anteriores mostraban lenguajes donde el sistema de tipos regala la mitad estructural del statechart y el resto lo escribes tú. Erlang invierte el reparto entero. Aquí no hay tipos que comprueben nada al compilar, pero sí existe, desde hace un cuarto de siglo, un comportamiento de la biblioteca estándar cuyo único propósito es ejecutar máquinas de estados, con una lista de primitivas que a cualquiera que venga de XState le resultará familiar hasta la incomodidad y que en varios puntos la supera. La razón de esa madurez es histórica y vale la pena entenderla: Erlang nació para centralitas telefónicas, y una centralita es literalmente un enjambre de protocolos con estados, temporizadores y eventos que llegan a destiempo. Lo que en la web se descubrió hacia 2018 como una buena forma de organizar una interfaz, allí fue desde el primer día la única forma concebible de escribir el sistema.

El nombre del estado y los datos del estado

El comportamiento gen_statem apareció en OTP 19 y jubiló a gen_fsm, que quedó obsoleto en OTP 20. La sustitución no fue cosmética: corrigió tres limitaciones que en su antecesor obligaban a componendas constantes, a saber, la imposibilidad de aplazar un evento, la falta de temporizadores asociados al estado y la obligación de que el estado fuera siempre un átomo. La abstracción que resultó descompone el estado en dos mitades que el resto de este track lleva veintitantos niveles distinguiendo: el nombre del estado, que determina qué eventos son legales, y los datos del estado, que son el estado extendido y viajan con la máquina sin cambiar qué es legal.

Esa descomposición da lugar a los dos modos de retrollamada, y elegir entre ellos es la primera decisión de diseño. Con state_functions, el nombre del estado debe ser un átomo y cada estado tiene su propia función, de modo que el código queda agrupado por estado y leer un estado completo es leer una función. Con handle_event_function, hay una sola retrollamada de cuatro argumentos, el nombre del estado puede ser cualquier término —una tupla, un mapa, algo compuesto— y el código puede agruparse por evento, que es lo que conviene cuando muchos estados reaccionan igual a lo mismo. Añadir state_enter a la lista del modo activa además las llamadas de entrada, que son las acciones de entrada de Harel con otro nombre.

defmodule Torniquete do
  @behaviour :gen_statem
  require Logger

  def start_link, do: :gen_statem.start_link({:local, __MODULE__}, __MODULE__, :ok, [])
  def moneda, do: :gen_statem.call(__MODULE__, :moneda)
  def empujar, do: :gen_statem.cast(__MODULE__, :empujar)

  @impl true
  def callback_mode, do: [:state_functions, :state_enter]

  @impl true
  def init(:ok), do: {:ok, :bloqueado, %{monedas: 0, giros: 0}}

  def bloqueado(:enter, _anterior, _datos) do
    Logger.info("torniquete bloqueado")
    :keep_state_and_data
  end

  def bloqueado({:call, quien}, :moneda, datos) do
    {:next_state, :abierto, %{datos | monedas: datos.monedas + 1},
     [{:reply, quien, :ok}, {:state_timeout, 5_000, :caduco}]}
  end

  def bloqueado(:cast, :empujar, _datos) do
    {:keep_state_and_data, [:postpone]}
  end

  def abierto(:enter, _anterior, _datos), do: :keep_state_and_data

  def abierto(:cast, :empujar, datos) do
    {:next_state, :bloqueado, %{datos | giros: datos.giros + 1}}
  end

  def abierto(:state_timeout, :caduco, datos) do
    {:next_state, :bloqueado, datos}
  end

  def abierto({:call, quien}, :moneda, _datos) do
    {:keep_state_and_data, [{:reply, quien, {:error, :ya_abierto}}]}
  end
end

La versión equivalente en el otro modo revela para qué sirve de verdad: cuando el nombre del estado puede ser un término compuesto, la jerarquía y las regiones dejan de ser algo que hay que aplanar a mano. Un estado escrito como una tupla de modo y submodo permite escribir manejadores que atienden a todos los submodos de un modo con una sola cláusula, que es exactamente el comportamiento de un estado compuesto de Harel expresado con coincidencia de patrones.

def callback_mode, do: :handle_event_function

# atiende cualquier submodo del modo conectado
def handle_event(:cast, :desconectar, {:conectado, _submodo}, datos) do
  {:next_state, :desconectado, %{datos | sesion: nil}}
end

# solo el submodo de espera
def handle_event(:state_timeout, :sin_respuesta, {:conectado, :esperando}, datos) do
  {:next_state, {:conectado, :inactivo}, datos}
end

Esa capacidad tiene contrapartida y conviene enunciarla antes de abusar de ella: al agrupar por evento se pierde la lectura por estado, que es la gran virtud del primer modo, y con nombres compuestos el conjunto de estados deja de estar enumerado en ningún sitio, de modo que nada impide inventar una tupla que no corresponde a ningún estado real. La regla práctica que aplica la mayoría del ecosistema es empezar con funciones por estado, que se leen como el diagrama, y cambiar de modo solo cuando la jerarquía o la repetición entre estados lo justifiquen.

Las acciones que casi ninguna otra herramienta trae

La lista de retorno de una retrollamada no se limita al estado siguiente: incluye una lista de acciones que el motor ejecuta en orden, y ahí está la parte que conviene mirar despacio porque es donde gen_statem aventaja a la mayoría de las librerías modernas.

Las tres últimas filas merecen comentario porque no son comodidades. La respuesta síncrona permite que un cliente llame a la máquina y espere el resultado, pero la máquina decide desde dentro de la transición cuándo y qué contestar, e incluso puede no contestar todavía y guardar el remitente en sus datos para responderle cuatro estados después: eso es una petición que espera a que un protocolo avance, y es endiabladamente difícil de escribir sin un motor que lo contemple.

El aplazamiento es la joya. Cuando un evento llega en un estado donde aún no tiene sentido, el manejador puede pedir que se guarde en lugar de descartarlo, y el motor lo vuelve a entregar automáticamente en cuanto el nombre del estado cambia, respetando el orden de llegada. Piensa en un cliente que envía peticiones mientras la conexión aún se está estableciendo: sin aplazamiento hay que inventar una cola en el estado extendido, drenarla a mano al entrar en el estado bueno y no equivocarse con el orden. Con aplazamiento son cinco caracteres. El precio, que hay que decir, es que un evento aplazado que nunca encuentra un cambio de estado se acumula en memoria para siempre, de modo que aplazar sin un temporizador de estado que garantice la salida es una fuga esperando su turno. En el torniquete de arriba, además, aplazar el empujón es discutible como decisión de producto —lo razonable en una puerta real es descartarlo— y aparece ahí para que veas el mecanismo, no para que lo copies.

El proceso es el actor y el estado no sobrevive por defecto

Todo lo anterior sería una biblioteca elegante si no fuera porque cada máquina es además un proceso de la BEAM: tiene su propio montículo, su propio buzón, su planificación expropiativa y su identificador. Eso significa que instanciar diez mil máquinas es una operación normal y barata, que ninguna puede corromper la memoria de otra, que un fallo en una no arrastra a las demás y que la comunicación entre máquinas es un envío de mensaje al buzón del vecino, con la máquina receptora decidiendo en qué estado ese mensaje significa algo.

flowchart TD
S[supervisor] -->|arranca y vigila| A[proceso gen statem sesion A]
S -->|arranca y vigila| B[proceso gen statem sesion B]
A -->|mensaje sincrono con respuesta diferida| B
B -.->|falla y muere| S
S -.->|reinicia en el estado inicial| B
B -->|escribe lo que debe durar| T[almacen fuera del proceso]
style A fill:#a6e3a1,color:#11111b
style T fill:#89dceb,color:#11111b

De ahí se sigue la consecuencia que más sorprende a quien llega desde una interfaz de usuario y la que hay que enunciar sin adornos: el estado de un gen_statem no es duradero. Vive en el montículo del proceso y desaparece cuando el proceso muere, de modo que el supervisor que lo reinicia arranca una máquina nueva en el estado inicial, no la misma máquina donde la dejó. Esto no es un defecto que OTP no llegó a resolver, es una decisión: la máquina modela el protocolo en curso, que por naturaleza es efímero, y lo que debe sobrevivir a una caída se escribe explícitamente fuera del proceso, en una tabla en memoria compartida, en una base de datos o en un registro de eventos. La distinción entre lo que la máquina está haciendo ahora y lo que el sistema debe recordar pase lo que pase queda así separada por construcción, y esa separación es justamente la que los motores de flujos de trabajo duraderos reintroducen a base de persistir cada transición.