Kubernetes: presupuesto de errores para emails de prueba

Una prueba de email puede terminar en verde aunque el mensaje nunca haya llegado al buzón correcto. El job creó una dirección, llamó al proveedor y recibió un 200; sin embargo, un timeout posterior, un worker duplicado o una limpieza demasiado rápida pueden esconder el fallo real.

En equipos que operan Kubernetes, conviene tratar estas pruebas como una pequeña operación distribuida. El objetivo no es mantener un buzón abierto para siempre, sino definir qué significa éxito, cuánto tiempo se espera y qué evidencia queda cuando algo sale mal. Un generador de correo desechable puede ayudar a inspeccionar una entrega aislada, pero no reemplaza los límites ni la observabilidad del job.

El síntoma: una prueba verde que no demuestra entrega

El flujo típico tiene cuatro pasos:

1. El test crea una dirección de prueba.
2. La aplicación envía el email de verificación.
3. El test consulta el buzón hasta encontrar el mensaje.
4. Kubernetes marca el pod como completado.

El problema aparece cuando solo se registra el resultado final. Un exit 0 no dice si el mensaje llegó en el primer intento, después de tres reintentos, o justo antes de que venciera el timeout. Tampoco permite distinguir entre un proveedor lento y una consulta que estaba mirando el buzón equivocado.

Un caso de uso que confunde bastante es escribir "tempail mail" en el fixture y luego buscarlo con otra normalización. La prueba puede fallar por datos inconsistentes, no por el sistema bajo prueba. Por eso el contrato de la prueba debe incluir dirección, identificador de ejecución, asunto esperado y ventana de espera.

Define el presupuesto de errores del job

Un presupuesto de errores no significa aceptar fallos sin investigar. Es un límite explícito para que el test no se convierta en un consumidor infinito de tiempo y mensajes.

Antes de crear el job, fija estos valores:

• Tiempo total: cuánto puede durar la prueba completa.
• Intentos de consulta: cuántas veces se revisa el buzón.
• Intervalo: cuánto se espera entre consultas.
• Mensajes aceptables: si se permite un duplicado o solo uno.
• Evidencia mínima: qué datos se guardan cuando termina.

Por ejemplo, una prueba de verificación puede tener un límite de 90 segundos, seis consultas y un máximo de un mensaje con el asunto esperado. Si el proveedor tarda más, el resultado es una alerta investigable, no un polling que mantiene un runner ocupado durante horas.

La métrica útil no es solo “pasó o falló”. Registra el tiempo hasta la primera observación, el número de intentos y la razón final. Así el equipo puede distinguir una degradación gradual de un fallo de autenticación.

Conserva una evidencia pequeña y útil

Guardar el mensaje completo en cada ejecución suele ser innecesario y puede introducir datos sensibles en los artefactos de CI. Es mejor conservar una evidencia mínima:

{
  "run_id": "signup-2026-09-26-0042",
  "address_hash": "sha256:...",
  "subject": "Confirma tu cuenta",
  "provider_message_id": "msg_123",
  "poll_attempts": 3,
  "observed_after_ms": 18400,
  "result": "received"
}

El hash evita publicar la dirección de prueba sin perder la capacidad de correlacionar logs. El provider_message_id ayuda cuando hay que pedir ayuda al proveedor. Si el contenido es importante, conserva un extracto saneado y una aserción sobre el enlace, no el token completo.

En la interfaz de la aplicación también importa el contrato. Un usuario debe saber si el email está pendiente, si expiró o si debe solicitar otro. El artículo sobre feedback estable al enviar emails muestra una preocupación cercana desde el frontend; para un test de CI, la misma claridad debe existir en los estados del job.

Reintentos y limpieza en Kubernetes

Kubernetes puede reintentar un Job fallido, y el propio test puede volver a consultar el buzón. Si ambos reintentan sin coordinación, una sola ejecución lógica acaba creando varios mensajes y el resultado se vuelve dificil de interpretar.

Un manifiesto básico puede hacer visible el límite:

apiVersion: batch/v1
kind: Job
metadata:
  name: email-smoke
spec:
  backoffLimit: 1
  activeDeadlineSeconds: 120
  ttlSecondsAfterFinished: 86400
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: test
          image: registry.example.com/email-smoke:2026.09.26
          env:
            - name: POLL_ATTEMPTS
              value: "6"
            - name: POLL_INTERVAL_SECONDS
              value: "15"

activeDeadlineSeconds protege el clúster de un test colgado. backoffLimit limita las ejecuciones adicionales del pod, mientras que el propio proceso limita las consultas al buzón. El TTL permite investigar durante un día sin acumular jobs para siempre.

La limpieza debe ocurrir después de publicar la evidencia. Si se elimina primero la dirección o el artefacto, el incidente queda sin contexto. Un orden razonable es: terminar el test, escribir el resultado, subir el artefacto, y solo entonces borrar los recursos temporales.

Para el navegador, conviene probar también los estados de carga que verá la persona que espera el mensaje. Los estados de carga rápidos y accesibles son una buena referencia para no interpretar una espera normal como un error prematuro.

Qué debe alertar un SRE

No toda prueba fallida merece una alerta de página. Un SRE debería separar señales operativas de defectos de producto:

• Una subida sostenida del tiempo de entrega sugiere degradación del proveedor.
• Muchos 401 o 403 apuntan a credenciales o permisos mal configurados.
• Mensajes duplicados pueden indicar reintentos sin idempotencia.
• Buzones vacíos con respuestas exitosas requieren revisar el enrutamiento.
• Jobs que alcanzan el deadline señalan una política de espera demasiado optimista.

Es útil etiquetar cada métrica con entorno, proveedor y versión del test, pero no con la dirección completa. Las alertas debe incluir el run_id y un enlace al artefacto, no datos personales.

Checklist antes de confiar en el resultado

• ¿El test tiene un run_id único y una dirección aislada?
• ¿El contrato define asunto, destinatario y número de mensajes?
• ¿Hay límites separados para polling y reintentos de Kubernetes?
• ¿Se guarda el identificador del proveedor y el tiempo de entrega?
• ¿El artefacto se publica antes de la limpieza?
• ¿Los logs evitan tokens, contenido privado y direcciones sin enmascarar?
• ¿Una prueba lenta queda clasificada como señal, no como éxito?

El presupuesto de errores hace que una prueba de email sea más honesta. No garantiza que el proveedor nunca falle, pero deja claro cuanto se esperó, qué se observó y qué debe hacer el equipo después. Esa es la diferencia entre un job verde y una señal en la que un equipo SRE puede confiar.