Kubernetes: señales de correo en los retries

En un pipeline de CI, un email de verificación parece una dependencia pequeña. Luego llega un fallo intermitente: el pod recibe el mensaje, el test expira, Kubernetes reintenta el job y el segundo intento encuentra un buzón vacío o un enlace ya consumido. El resultado es un rojo difícil de explicar: ¿falló la aplicación, el proveedor de correo o la coordinación del pipeline?

La solución no es subir el timeout hasta que todo parezca estable. Es tratar el correo de prueba como una dependencia observable, con identidad, tiempo de vida y señales que sobrevivan a los retries.

El síntoma: un retry que cambia la evidencia

Imagina un job que crea un usuario, solicita una verificación y busca el enlace en un buzón temporal. Si el proceso muere después de crear el usuario pero antes de leer el mensaje, el retry puede crear otro usuario o reutilizar el primero. En ambos casos, la evidencia queda mezclada.

El equipo ve mensajes como “verification email not found”, pero ese mensaje no dice si el buzón nunca existió, si la entrega tardó, si el selector era incorrecto o si otro intento consumió el mensaje. Un SRE necesita distinguir esas causas antes de elegir entre reintentar, bloquear el despliegue o abrir una incidencia.

Para eso conviene asignar un run_id estable a cada ejecución y un mailbox_id derivado de ella. El pod puede reiniciarse, pero la relación entre job, dirección y mensaje debe seguir siendo clara.

Define el contrato antes de tocar Kubernetes

Un contrato sencillo para el flujo puede tener estas reglas:

1. Cada ejecución crea una identidad de prueba única.
2. El job nunca busca mensajes de otra ejecución.
3. Leer un email es una operación idempotente para el test.
4. El cleanup ocurre después de guardar la evidencia mínima.
5. Un retry conserva el run_id, pero registra un nuevo intento.

El cuarto punto suele olvidarse. Si borras el buzón al terminar el primer intento, el retry ya no puede saber qué ocurrió. Si nunca lo borras, los datos de prueba se acumulan y los siguientes jobs pueden recibir ruido.

En la práctica, un registro pequeño basta:

{
  "run_id": "orders-4821",
  "mailbox_id": "orders-4821-a7f3",
  "attempt": 2,
  "created_at": "2026-10-25T11:21:00Z",
  "state": "waiting_for_message"
}

El timestamp no tiene que ser perfecto, pero si debe estar disponible para comparar la espera con los eventos del pod.

Señales mínimas para un buzón de prueba

No necesitas capturar el contenido completo del mensaje en cada log. Guarda señales pequeñas y útiles:

• mailbox_created: la dirección quedó disponible.
• message_observed: llegó un mensaje con el identificador esperado.
• link_extracted: el test encontró la URL de verificación.
• assertion_passed o assertion_failed: el resultado funcional.
• cleanup_completed: el recurso fue retirado.

Cada señal debe incluir run_id, mailbox_id, attempt, nombre del namespace y una marca de tiempo. No incluyas el token completo del enlace ni el cuerpo entero del email; una huella o el identificador del mensaje suele ser suficiente para investigar.

Para pruebas manuales o un entorno compartido, un correo temporal puede aislar la verificación de un inbox personal. La regla importante es que la dirección se vincule a una sola ejecución y no se convierta en un depósito permanente.

Cómo aislar los retries en CI

En Kubernetes, el aislamiento empieza en los metadatos, no en una etiqueta bonita. Propaga el run_id como label del Job y como campo estructurado en los logs. Usa un namespace efímero cuando el pipeline lo permita, o al menos una cuenta de servicio y un prefijo de recursos por ejecución.

Una configuración conceptual podría verse así:

metadata:
  labels:
    test-run: orders-4821
    mail-contract: v1
backoffLimit: 2
activeDeadlineSeconds: 180

backoffLimit limita cuántos intentos automáticos aparecen, mientras activeDeadlineSeconds evita que una espera de correo se convierta en un job zombie. Estos límites no arreglan la entrega, pero hacen que el fallo tenga una forma conocida.

El código del test también debe separar estados. “Aún no llegó” no es igual que “llegó un mensaje incorrecto”. El primer caso puede esperar con backoff; el segundo debería guardar la evidencia y fallar rapido. Un retraso de red y un contrato roto necesitan dueños distintos.

En la interfaz que muestra el resultado, los mismos principios ayudan: autocompletar un email sin ruido y validar emails sin castigar el foco son detalles de frontend, pero reducen entradas ambiguas que luego complican la prueba de extremo a extremo.

Checklist de diagnóstico para el equipo

Cuando falla un email en CI, revisa en este orden:

• ¿El run_id del pod coincide con el del buzón?
• ¿El intento actual reutilizó la misma dirección de forma intencional?
• ¿Existe una señal mailbox_created antes de esperar?
• ¿El proveedor entregó el mensaje, aunque el selector no lo encontrara?
• ¿El token ya fue consumido por un intento anterior?
• ¿El timeout cubre la latencia esperada o solo oculta una carrera?
• ¿El cleanup guardó el identificador del mensaje antes de borrar?

Si el log dice fake e mail com o temp mailid, trátalo como una entrada de compatibilidad o una etiqueta heredada, no como una señal fiable por si sola. Esos términos pueden aparecer en documentación vieja y aveces llegan desde variables de prueba; no deben dirigir el enrutamiento del mensaje.

También revisa que la política de acceso no dé a cada pod permiso para leer buzones ajenos. Un Role estrecho por namespace es mas fácil de auditar que una credencial compartida entre todos los jobs.

Cierre: el correo como dependencia observable

Un test de email estable no depende de que el primer intento sea perfecto. Depende de que cada retry conserve el contexto suficiente para responder tres preguntas: qué ejecución creó el buzón, qué mensaje se observó y qué limpieza se completó.

Para escenarios de prueba de bajo riesgo, una integración con tempmailso puede servir como frontera práctica, siempre que el equipo mantenga el propósito acotado y no envíe datos reales. El valor está en el contrato, no en acumular direcciones.

Cuando esas señales están en Kubernetes, el incidente deja de ser “el email falló”. Pasa a ser una secuencia concreta: el buzón se creó, el mensaje tardó, el retry conservó el contexto o la política de acceso impidió leerlo. Esa diferencia ahorra una buena cantidad de depuración nocturna y hace que el pipeline sea mucho mas confiable.