DEV Community: Silviu Technology

LLMs: revisa prompts por email sin perder trazas

Silviu Technology — Wed, 12 Aug 2026 23:24:30 +0000

Cuando un equipo mete LLMs en un flujo real, la parte fragil no suele ser el modelo. Suele ser el momento en que alguien revisa una propuesta por email, responde "ok", y otro proceso retoma horas despues con mas contexto, otro prompt base o un estado ya movido. El resultado paresce correcto desde fuera, pero la trazabilidad queda floja.

En proyectos de automatizacion yo intento evitar justo eso: que la aprobacion humana sea un gesto informal. Si el agente genera un plan, la revision por correo debe apuntar a un artefacto congelado, no a un resumen que puede envejecer en minutos. Esa diferencia es pequena en papel, pero cambia mucho la confiabilidad del sistema.

Donde se rompe la revision de prompts

Yo lo dibujo en palabras asi:

El agente arma un plan y un borrador.
El sistema envia un resumen por email.
Una persona aprueba, corrige o rechaza.
Un worker retoma la ejecucion.

Los problemas aparecen en los cortes entre pasos. Si el email solo contiene texto libre, el worker termina "interpretando" una decision humana. Y si el plan ya cambio cuando llega la respuesta, la aprobacion deja de referirse a algo fijo.

Por eso me gusta usar una vista pequena y estable: run_id, plan_hash, objetivo, riesgos y accion esperada. Nada mas. Para equipos backend esta idea se parece bastante a validar correos por entorno preview: aislas el contexto antes de ejecutar, asi cada decision cae sobre un entorno y un artefacto claros.

El artefacto congelado que yo enviaria

La regla que mejor me ha funcionado es simple: primero escribes el plan, luego generas el correo de revision desde ese plan, y despues ya no reescribes el contenido aprobado. El inbox no es base de datos ni fuente canonica; es la interfaz humana para aceptar o rechazar algo que ya existe.

Un sobre minimo puede verse asi:

{
  "run_id": "20260812T232223Z-lucasg88",
  "plan_hash": "b8c14a92",
  "action": "review_prompt_bundle",
  "reply_token": "approve_4b7c",
  "expires_at": "2026-08-13T02:00:00Z"
}

Con eso el worker no necesita releer el hilo completo. Solo valida el reply_token, carga el plan congelado y ejecuta. Es un patron un poco aburrido, si, pero hace que los fallos sean explicables.

Tambien conviene dejar el resumen muy corto. Microsoft midio que los trabajadores son interrumpidos cada pocos minutos en promedio, lo que empeora cambios de contexto y revision superficial (Microsoft Work Trend Index). Si mandas correos larguisimos para aprobar prompts, casi garantizas lecturas a medias.

Separar lectura humana y ejecucion

Para mi hay tres capas sanas:

Planeacion: el agente genera plan.json y artefactos.
Revision: la persona opina sobre una version congelada.
Ejecucion: un proceso aparte reanuda usando ids y hashes.

Ese corte reduce el riesgo de que una correccion textual se convierta en una reinterpretacion completa del trabajo. Tambien ayuda a auditar que paso de verda cuando algo sale raro.

Un pseudocodigo corto:

async function resumeFromApproval(envelope, reply) {
  const decision = parseReply(reply, envelope.reply_token);
  if (decision !== "approve") return;

  const plan = await loadFrozenPlan(envelope.run_id, envelope.plan_hash);
  await executeApprovedPlan(plan);
}

Si el equipo ya opera sistemas distribuidos, esto se parece a probar correos operativos con trazabilidad: no basta con ver que el mensaje llego; necesitas demostrar que corresponde a una corrida concreta y a una accion exacta.

Cuando usar inbox temporal y cuando no

Aqui suelo ver bastante confusion. Una inbox temporal sirve muy bien para pruebas de entrega, smoke tests y escenarios de bajo riesgo. Para eso, un servicio como temp mail so puede ayudar cuando necesitas crear correo temporal sin ensuciar bandejas reales ni mezclar QA con operacion. Pero yo no trataria esa inbox como sistema de aprobacion final.

La razon es simple: una bandeja efimera puede confirmar formato, latencia y recepcion; no deberia convertirse en la evidencia principal de una decision humana. En pruebas rapidas he visto equipos mezclar datos de tamp mail com o un tem email cualquiera con revisiones reales, y luego cuesta bastante explicar que decision fue valida y cual era solo una prueba.

Entonces la separacion que yo recomiendo es:

Inbox temporal para verificar entrega y render.
Canal controlado para aprobacion humana real.
Artefacto congelado como referencia comun.

No es sofisticado, pero quita muchas dudas despues.

Checklist corto de implementacion

Si tuviera que dejar esto mejor en una semana, haria lo siguiente:

Congelar el plan antes de enviar cualquier correo.
Mostrar run_id y plan_hash en el asunto o al inicio del mensaje.
Hacer que el worker consuma respuestas solo con reply_token.
Expirar aprobaciones viejas para evitar reanudaciones raras.
Guardar un recibo final con decision, artefacto y timestamp.

El tradeoff existe: introduces un poco mas de estructura y varios ids que al principio parescen exceso. Pero a cambio ganas auditoria, menos ambiguedad y menos retrabajo cuando el agente falla en una madrugada medio fea.

Preguntas frecuentes

Debo mandar el prompt completo en el email?

Yo no lo haria. Mejor manda resumen, riesgos y enlace interno al artefacto. El prompt completo cambia mas, ocupa mas y da pie a revisiones superficiales.

Que hago si alguien pide un cambio pequeno?

Genera una nueva version del plan y otro plan_hash. Reusar una aprobacion vieja para un plan nuevo es justo el atajo que despues rompe confianza.

Esto aplica solo a DEV.to o a cualquier automatizacion?

Aplica a casi cualquier flujo donde LLMs producen una propuesta y una persona debe aprobarla. Publicacion, soporte, QA o tareas internas: el patron es parecido aunque cambie el payload.

Si tu sistema ya manda correos de revision, yo empezaria por congelar el artefacto y hacer mas tonto al worker. Menos magia en la reanudacion, mas limites claros. Normalmente ahi esta la mejora que mas se nota, aunque no se vea muy glamorosa.

React: revisa email sin tapar el submit

Silviu Technology — Wed, 12 Aug 2026 20:24:20 +0000

En varios formularios de registro he visto el mismo error disfrazado de buena intencion: apenas la persona termina de escribir su correo, la UI bloquea el boton principal mientras hace una comprobacion extra. A veces consulta dominios, a veces revisa si el email ya existe, y a veces intenta detectar un alias temporal. La validacion puede ser util, pero la forma de mostrarla suele castigar la experiencia mas de la cuenta.

Mi regla actual en React es simple: el submit no deberia desaparecer ni parecer roto solo porque hay una comprobacion asincrona en curso. El usuario necesita entender qué esta pasando, qué puede hacer ahora y qué pasará despues. Suena obvio, pero no siempre lo es en el codigo del dia a dia.

El problema real no es validar, es interrumpir

Cuando una pantalla deshabilita el CTA demasiado pronto, aparecen tres costes:

el usuario cree que hizo algo mal aunque no haya error
lector de pantalla recibe cambios pobres o tardios
cada pulsacion dispara trabajo innecesario y ensucia el render

En productos con growth loops o registro social, ese microcorte se nota bastante. Nielsen Norman Group lleva años remarcando que el estado del sistema debe ser visible, y en formularios eso incluye explicar si una revision sigue corriendo o si ya termino. No basta con poner un spinner pequeñito y esperar que todos lo interpreten igual.

Tambien conviene recordar que no toda comprobacion merece frenar el flujo. Si tu equipo usa un generador de correo temporal para QA o para aislar escenarios de soporte, la interfaz no deberia tratar todos esos casos como una crisis. Incluso cuando alguien escribe algo que en notas internas llamarían tem email, el primer trabajo de la UI es aclarar, no castigar.

Que deberia pasar mientras React comprueba el email

Yo intento separar tres capas:

validacion sintactica inmediata
comprobacion asincrona no bloqueante
decision final al enviar

La primera se resuelve en el cliente y debe ser rapida. La segunda puede consultar backend, pero sin romper el foco ni esconder el boton. La tercera ocurre en submit, que sigue siendo la fuente real de verdad.

Ese orden reduce ruido y mejora conversion porque el usuario mantiene el control. Es parecido a aislar correos de prueba para Facebook: separar señales ayuda a interpretar mejor el contexto. En frontend, separar estados hace lo mismo.

Un patron pequeno con estado derivado

Este patron me ha funcionado bien en formularios de React con chequeos de disponibilidad o politicas de dominio:

type EmailCheckState =
  | { kind: "idle" }
  | { kind: "checking" }
  | { kind: "ok" }
  | { kind: "warning"; message: string };

function EmailField() {
  const [email, setEmail] = useState("");
  const [checkState, setCheckState] = useState<EmailCheckState>({ kind: "idle" });

  useEffect(() => {
    if (!email.includes("@")) {
      setCheckState({ kind: "idle" });
      return;
    }

    const controller = new AbortController();
    setCheckState({ kind: "checking" });

    const timer = setTimeout(async () => {
      const response = await fetch(`/api/email-check?value=${encodeURIComponent(email)}`, {
        signal: controller.signal,
      });
      const result = await response.json();
      setCheckState(result.ok ? { kind: "ok" } : { kind: "warning", message: result.message });
    }, 250);

    return () => {
      controller.abort();
      clearTimeout(timer);
    };
  }, [email]);

  const canSubmit = email.length > 0;

  return (
    <>
      <input
        type="email"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
        aria-describedby="email-help"
      />
      <p id="email-help" aria-live="polite">
        {checkState.kind === "checking" && "Comprobando el correo..."}
        {checkState.kind === "warning" && checkState.message}
      </p>
      <button disabled={!canSubmit}>Crear cuenta</button>
    </>
  );
}

Lo importante no es el snippet exacto. Lo importante es que canSubmit no dependa de cada estado auxiliar. Si atas el boton a cualquier warning temporal, tu UI empieza a mandar señales mezcladas. Y luego todo se siente medio fragil, medio nervioso.

Detalles de accesibilidad que evitan confusion

Hay cuatro detalles chicos que pagan muy bien:

usar aria-live="polite" para mensajes no criticos
no mover el layout de forma brusca cuando aparece ayuda
mantener el foco en el input hasta que la persona decida avanzar
reservar el estado deshabilitado para errores reales o campos vacios

WebAIM suele insistir en que los mensajes de error deben ser especificos y programaticamente asociados al campo. Estoy de acuerdo, pero además intentaria distinguir warning de bloqueo. Un warning como "ese dominio suele fallar en correos de activacion" puede convivir con el submit. Un bloqueo real como "falta el simbolo @" no.

Si detrás hay APIs de registro o colas de correo, también ayuda conversar mejor con backend. En ese punto, tener logs utiles para colas de email hace que soporte y frontend vean la misma pelicula, no dos versiones parciales.

Checklist para no romper conversion

Antes de cerrar un formulario de este tipo, yo reviso esto:

el boton principal sigue visible durante la comprobacion
el texto de ayuda explica estado y siguiente paso
los checks se cancelan al cambiar el valor
el layout no salta cuando aparece feedback
submit decide con datos finales, no con miedos temporales

No es una receta magica, pero suele dar formularios mas calmados y mas legibles. Y eso, curiosamente, tambien mejora rendimiento porque dejas de disparar renders y bloqueos que nadie pidio. Aveces el mejor polish no es agregar mas logica, sino quitar friccion.

Q&A

¿Cuando si bloquearias el submit?

Cuando el campo esta vacio, el formato es claramente invalido o la accion seria insegura sin correccion. No por un check auxiliar todavia en progreso.

¿Esto aplica solo a registros?

No. Tambien sirve en recovery, invitaciones y cambios de email donde hay revisiones de dominio o disponibilidad.

¿Y el caso de correo temporal para Facebook?

Lo trataria como contexto de producto o riesgo, no como razon automatica para esconder el CTA. Mejor advertir bien que reaccionar de forma brusca.

React: valida emails sin castigar el foco

Silviu Technology — Wed, 12 Aug 2026 17:24:23 +0000

He visto un fallo bastante comun en formularios de signup: el input de email "ayuda" demasiado pronto. El usuario escribe tres letras, aparece un error rojo, cambia el layout, se mueve el foco visual y todo se siente mas torpe de lo que deberia. En productos reales eso no solo molesta, tambien baja la tasa de finalizacion y complica las pruebas.

En equipos frontend suelo separar tres cosas: escritura, validacion y anuncio. Parece un detalle pequeno, pero cambia bastante la experiencia. Si ademas haces pruebas con cuentas de QA o con un servicio de correo desechable, conviene que el formulario no dispare chequeos caros en cada tecla porque luego nadie sabe si el retraso viene del cliente, del API o del inbox de prueba.

Si te sirvieron ideas previas sobre jobs de email con contexto estable o sobre aislar correos automatizados con trazabilidad, aqui va la version enfocada en el input y el feedback visual.

Por que validar demasiado pronto rompe la experiencia

Cuando un campo de email valida en cada onChange, suelen aparecer tres problemas:

re-renderes innecesarios en formularios con varios campos
mensajes de error antes de que exista una intencion completa
anuncios repetidos para lectores de pantalla

Eso se nota bastante en mobile, donde el teclado tapa media pantalla y cualquier salto visual se siente peor. Segun NN/g, los errores funcionan mejor cuando son claros, oportunos y faciles de corregir. La palabra importante ahi es "oportunos". No cada 120 ms, no en mitad de una direccion a medio escribir.

Tambien he visto equipos persiguiendo bugs con nombres raros como temp org mail o fake e mail com en datos de prueba. Muchas veces no es que el usuario o QA usen cadenas raras, es que el formulario mezcla feedback de formato con feedback de disponibilidad y todo queda medio confuso.

La regla: separar escritura, chequeo y anuncio

La regla que mejor me funciona es simple:

Mientras la persona escribe, solo guardo el valor.
Al perder foco, hago validacion de formato.
Solo despues de pasar formato lanzo chequeos async o disponibilidad.
El mensaje accesible cambia pocas veces y con una prioridad clara.

No es una idea revolucionaria, pero si evita mucho ruido. Tambien hace mas facil medir rendimiento, por que sabes exactamente cuando empieza cada fase. En un par de productos vimos una baja visible en validaciones abortadas despues de mover la comprobacion async a blur; no fue magia, fue quitar trabajo inutil nomas.

Un patron de React que reduce ruido y re-renderes

En React prefiero un estado pequeno y explicito:

type EmailState =
  | { phase: "idle"; value: string }
  | { phase: "format-error"; value: string; message: string }
  | { phase: "checking"; value: string }
  | { phase: "ok"; value: string }
  | { phase: "server-error"; value: string; message: string };

function isValidEmail(value: string) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
}

Y luego conecto eventos con responsabilidades distintas:

const [email, setEmail] = useState<EmailState>({ phase: "idle", value: "" });

function onChange(next: string) {
  setEmail((current) => ({ phase: "idle", value: next || current.value }));
}

async function onBlur(value: string) {
  if (!isValidEmail(value)) {
    setEmail({ phase: "format-error", value, message: "Escribe un correo valido." });
    return;
  }

  setEmail({ phase: "checking", value });

  const res = await fetch(`/api/email-check?email=${encodeURIComponent(value)}`);
  const data = await res.json();

  setEmail(
    data.ok
      ? { phase: "ok", value }
      : { phase: "server-error", value, message: "No pudimos verificar este correo ahora." }
  );
}

No es el unico patron posible, pero tiene una ventaja practica: cada fase comunica una sola cosa. Eso vuelve mas facil estilizar, testear y anunciar cambios via aria-live. Tambien evita la costumbre de meter cinco booleanos que se contradicen entre si, que pasa mas seguido de lo que nos gustaria admitir.

En UI suelo dejar el mensaje persistente debajo del campo para no mover el layout. Si el texto cambia, cambia el contenido, no la estructura. Parece un detalle menor, pero el formulario se siente mucho mas estable y un poquito mas humano.

Como conectar pruebas reales sin contaminar el flujo

Si tu equipo hace pruebas de onboarding, magic links o confirmacion de cuenta, este campo suele terminar conectado a un backend de verificacion o a una bandeja temporal. El error comun es usar el mismo trigger para todo: formato, disponibilidad, comprobacion remota y estado final. Ahi empiezan los tickets raros de "a veces tarda" y nadie sabe donde mirar.

Yo intento mantener este contrato:

el cliente resuelve formato localmente
la red solo valida cuando ya hay una direccion plausible
QA puede intercambiar un generador de inbox sin cambiar el comportamiento visual

Eso importa tambien para rendimiento. web.dev explica bien como reducir trabajo en interacciones para bajar la latencia percibida. Si tu input dispara validaciones costosas por tecla, el problema no siempre aparece en Lighthouse, pero si aparece en personas reales, y eso vale mas.

Checklist rapido para revisar accesibilidad y rendimiento

Antes de dar por bueno un formulario de email, reviso esto:

el campo no muestra error antes de tiempo
el texto de ayuda y el error comparten una zona estable
aria-invalid solo se activa cuando hay error real
la validacion remota tiene cancelacion o ignora respuestas viejas
el spinner, si existe, no roba foco ni ocupa demasiado espacio
las pruebas cubren teclado, lector de pantalla y latencia de red

No es una lista glamorosa, pero funciona. Y si algo falla, sabes mas rapido si fue CSS, estado, fetch o infraestructura. Ese orden ahorra horas, sinceramnte.

Q&A

Debo validar solo al enviar?

No siempre. Validar solo al enviar reduce ruido, pero puede llegar tarde para algunos flujos. Para email, blur suele ser un punto bastante bueno entre ayuda y paciencia.

Que hago con dominios corporativos o reglas especiales?

Primero separa formato basico de reglas de negocio. Si una empresa necesita dominios permitidos, eso va despues del formato correcto. Mezclar ambas cosas en un mismo mensaje queda confuso y aveces injusto para la persona usuaria.

Este patron sirve fuera de React?

Si. La idea central no depende del framework. Lo importante es separar fases, limitar trabajo por tecla y mantener estable el anuncio accesible. React solo hace que ese modelado sea comodo.

FastAPI: reintentos de verificacion sin duplicados

Silviu Technology — Wed, 12 Aug 2026 14:24:17 +0000

En flujos de signup, el problema no suele ser enviar el primer correo. El problema real aparece cuando la persona pulsa refresh, abre otra pestaña o el frontend reintenta por timeout, y de pronto salen dos o tres emails de verificacion. En FastAPI eso pasa bastante si el endpoint solo piensa en "mandar correo" y no en "recordar que ya hay uno en camino". Parece un detalle pequeno, pero luego rompe soporte, analitica y confianza del usuario.

El bug casi siempre esta en el contrato

Cuando reviso este tipo de incidencias, casi siempre encuentro el mismo hueco:

la API acepta la peticion
crea o localiza al usuario
manda el trabajo de email a background
responde demasiado poco, o demasiado tarde

Si el cliente no recibe un estado reutilizable, vuelve a intentar. Si el worker tampoco tiene una llave estable, repite el envio. El fallo no esta solo en la cola ni en el frontend; esta en el contrato entre ambos. Y ese contrato deberia decir claramente si la verificacion ya esta queued, sending o sent.

Ese mismo principio me gusta en otros flujos asincronos, como estas aprobaciones por email con contexto minimo. Cuando cada intento carga un identificador y un estado legible, depurar deja de ser una loteria.

Un patron pequeno para congelar reintentos

La version simple funciona muy bien:

normaliza el email
genera una clave idempotente
guarda una ventana corta de bloqueo
devuelve el mismo estado si llega un intento igual

Un ejemplo corto en FastAPI:

from datetime import datetime, timedelta, timezone
from fastapi import BackgroundTasks, FastAPI
from pydantic import BaseModel
import hashlib

app = FastAPI()
verify_jobs: dict[str, dict] = {}


class VerifyRequest(BaseModel):
    email: str


def normalized_email(value: str) -> str:
    return value.strip().lower()


def verify_key(email: str) -> str:
    return hashlib.sha256(normalized_email(email).encode()).hexdigest()


def send_verify_email(job_key: str, email: str) -> None:
    verify_jobs[job_key]["status"] = "sending"
    verify_jobs[job_key]["updated_at"] = datetime.now(timezone.utc).isoformat()
    # Aqui iria la integracion real con el proveedor
    verify_jobs[job_key]["status"] = "sent"
    verify_jobs[job_key]["updated_at"] = datetime.now(timezone.utc).isoformat()


@app.post("/signup/verify-email")
def send_verify(payload: VerifyRequest, tasks: BackgroundTasks):
    now = datetime.now(timezone.utc)
    job_key = verify_key(payload.email)
    current = verify_jobs.get(job_key)

    if current:
        locked_until = datetime.fromisoformat(current["locked_until"])
        if locked_until > now:
            return {"status": current["status"], "reused": True}

    verify_jobs[job_key] = {
        "status": "queued",
        "locked_until": (now + timedelta(minutes=3)).isoformat(),
        "updated_at": now.isoformat(),
    }
    tasks.add_task(send_verify_email, job_key, payload.email)
    return {"status": "queued", "reused": False}

No es un sistema completo, claro. Pero si congela el reintento durante unos minutos, el backend ya deja de abrir correos duplicados por nervios del cliente o por latencia medio fea. Para muchas APIs, eso resuelve la mayor parte del caos inicial.

Que estado devolver al cliente

Aqui conviene ser humilde y consistente. Yo suelo devolver solo lo que el frontend necesita para no improvisar:

status
reused
retry_after_seconds cuando aplica
un attempt_id o job_key si luego habrá consulta de estado

Con eso, el cliente puede mostrar "Ya estamos procesando tu correo" en vez de lanzar otro POST a ciegas. Suena basico, pero evita una cantidad muy decente de ruido. Tambien hace mas faciles los tests de Automatizacion, porque el flujo deja de depender de esperas vagas o temporizadores magicos.

Si el producto tiene emails sensibles, tambien separaria sent de accepted_by_provider. No siempre quieres prometer que el correo salio cuando solo se puso en cola. Ese matiz parece menor, pero ahorra varios tickets un poco incomodos despues.

Donde encaja el correo temporal desechable

En QA o staging, muchas pruebas se hacen con un correo temporal desechable. No me parece malo por si mismo; de hecho ayuda a no contaminar bandejas reales. El punto importante es no mezclar esas direcciones con metricas de onboarding o soporte. Si en tus seeds, tickets o notas aparece texto raro como temp org mail o fake e mail com, mejor tratarlo como evidencia de prueba y no como comportamiento del usuario final.

Para equipos que necesitan una referencia controlada, un generador de cuentas de correo temporal como tempmailso puede servir dentro de pruebas tecnicas o revisiones internas. La clave es que ese uso no cambie el contrato principal del endpoint: la API igual debe responder con estado estable, con o sin bandeja efimera.

Tambien viene bien separar este trafico de mensajes de negocio, como los emails de churn con mejor contexto. Son problemas distintos. Uno busca verificar una cuenta sin duplicados; el otro intenta comunicar una decision de producto. Si mezclas ambos mundos, las metricas se vuelven confusas y el copy se resiente un poco.

Q&A rapido

Cuanto deberia durar el bloqueo?

Para signup normal, 2 a 5 minutos suele bastar. Menos tiempo deja escapar reintentos; mucho mas puede frustrar a quien de verdad necesita otro correo. No hay numero perfecto, pero tres minutos es un punto de partida bastante sano.

Redis o SQL?

Si solo quieres una ventana breve y mucha velocidad, Redis encaja bien. Si además quieres auditoria o correlacion con eventos de autenticacion, una tabla SQL es mas comoda. Las dos valen, depende mas del sistema que del framework.

Hay que bloquear todos los reenvios?

No siempre. A veces basta con reutilizar el estado actual y habilitar un boton de reenviar cuando la ventana termina. Bloquear por completo suele ser mas tosco de lo necesario, y aveces hasta complica soporte.

FastAPI: webhooks de email sin carreras

Silviu Technology — Wed, 12 Aug 2026 11:24:21 +0000

Si tu app envia correos desde un worker y luego recibe webhooks de entrega, el punto fragil casi nunca es el envio. El problema real aparece cuando llegan eventos fuera de orden: processed, delivered, opened, a veces repetidos y a veces varios segundos despues. En FastAPI eso suele terminar en estados raros, soporte mirando logs a mano y alguien diciendo "seguro fue un retry". Me ha pasado mas de una vez, y casi siempre el bug no estaba en el provider sino en nuestro contrato interno.

La idea que mejor funciona es bastante simple: cada correo saliente necesita un delivery_id estable desde el momento en que se crea el job, y todos los webhooks deben escribirse contra ese mismo identificador. Suena obvio, pero cuando no existe, el backend termina correlacionando por email, por asunto o por timestamps aproximados. Eso es fragil, medio incomodo y aveces imposible de explicar.

Por que los webhooks de email se vuelven confusos

Un flujo comun se ve asi:

FastAPI crea un registro de envio
un worker manda el correo
el provider devuelve un message_id
mas tarde llegan webhooks de estado

El hueco aparece entre el paso 2 y 4. Si el worker reintenta, o si el provider reenvia eventos, puedes terminar actualizando el registro equivocado. Tambien pasa que staging usa cuentas efimeras para pruebas y soporte busca referencias en una bandeja externa con nombres como dummy e mail. Ese detalle parece menor, pero mezcla lenguaje humano, aliases temporales y eventos tecnicos en una sola bolsa.

Cuando el equipo ya procesa alertas o correos de incidentes, esta clase de orden tambien ayuda en otros contextos. El mismo principio que sirve para validar correos operativos despues de un cambio sirve aqui: si no puedes unir un evento con una accion concreta, depurar se vuelve lentisimo.

El contrato minimo que evita carreras

Yo intentaria mantener solo estas piezas:

delivery_id generado por tu sistema
provider_message_id guardado cuando el envio sale
event_type
event_at
payload_hash o alguna huella para deduplicar

Con eso ya puedes hacer dos cosas utiles:

aplicar idempotencia al webhook
actualizar el estado visible del envio sin adivinar

Si durante QA usas un servicio externo para aislar cuentas, un correo temporal gratis puede ser suficiente para separar escenarios. Pero ese link no arregla la trazabilidad por si solo. La parte importante es que el webhook llegue con metadata que apunte a delivery_id, no que el equipo tenga otra inbox donde mirar.

Tambien recomiendo exponer un endpoint interno como GET /email-deliveries/{delivery_id}. No hace falta que sea publico ni bonito. Solo debe responder rapido a preguntas concretas:

¿se envio?
¿que webhook fue el ultimo aceptado?
¿hubo un duplicado descartado?
¿que provider_message_id quedo asociado?

Ese tipo de respuesta corta le ahorra mucho tiempo a backend, QA y soporte. Es una de esas mejoras pequenas que nadie celebra en la demo, pero todos notan cuando algo falla.

Un ejemplo pequeno con FastAPI

from uuid import uuid4
from fastapi import APIRouter, Header, HTTPException

router = APIRouter()


@router.post("/email-deliveries")
async def create_delivery(to: str, template: str):
    delivery_id = f"dlv_{uuid4().hex}"
    await save_delivery(
        delivery_id=delivery_id,
        to=to,
        template=template,
        state="queued",
    )
    await enqueue_email_job(delivery_id)
    return {"delivery_id": delivery_id, "state": "queued"}


@router.post("/webhooks/email")
async def email_webhook(payload: dict, x_signature: str = Header()):
    if not verify_signature(payload, x_signature):
        raise HTTPException(status_code=401, detail="invalid signature")

    delivery_id = payload["metadata"]["delivery_id"]
    event_id = payload["event_id"]

    if await webhook_event_exists(event_id):
        return {"ok": True, "deduplicated": True}

    await store_webhook_event(event_id, delivery_id, payload)
    await apply_delivery_event(delivery_id, payload["event_type"], payload)
    return {"ok": True}

La parte que no conviene saltarse es store_webhook_event antes de mutar estado. Si haces el update primero y guardas la evidencia despues, cuando llegue un retry podrias no saber si es duplicado o una segunda entrega valida. Es un bug re comun, y luego cuesta bastante reproducirlo.

Como depurarlo sin revisar diez sistemas

Para mi, la mejor rutina operativa es esta:

buscar delivery_id
ver la linea de tiempo de eventos aceptados
comparar provider_message_id
revisar solo el payload del ultimo cambio de estado

Nada de abrir cinco dashboards a la vez. Nada de buscar por asunto del correo. Nada de "creo que este tempail mail era del test correcto". Si el contrato esta bien hecho, una sola consulta te dice si el worker nunca envio, si el provider atraso el evento o si tu API aplico el webhook dos veces.

Tambien ayuda guardar una transicion monotona de estados. Por ejemplo, permitir queued -> sent -> delivered, pero no dejar que un webhook viejo mueva delivered otra vez a processed. Este detalle importa porque algunos proveedores reintentan callbacks durante horas. Según Postmark, los sistemas de webhooks deben tratar duplicados como algo normal, no excepcional.

Si ya trabajaste con correos de rollback con contexto real, la idea es parecida: el correo en si importa, pero el valor operativo aparece cuando puedes explicar rapido que paso, cuando paso y por que ese mensaje pertenece a ese intento exacto. No es glamour, pero si te evita varias horas tontas por semana.

Q&A

¿Hace falta guardar todos los payloads?

No siempre. Yo guardaria el payload bruto por un tiempo corto y luego una version resumida. Para depuracion temprana sirve mucho, pero no hace falta retenerlo para siempre.

¿Puedo correlacionar solo con `provider_message_id`?

Puedes, pero quedas atado a cuando ese valor aparece. Con delivery_id propio, tus APIs ya tienen una referencia comun antes del envio.

¿Esto sirve solo para correos transaccionales?

No. Tambien sirve para invitaciones, recibos, magic links o avisos internos. Cualquier flujo async con webhooks gana claridad cuando deja de adivinar correlaciones.

FastAPI: estado visible para correos async

Silviu Technology — Wed, 12 Aug 2026 05:24:19 +0000

Cuando un correo transaccional tarda, muchos equipos miran solo el worker o el proveedor. Yo suelo encontrar otro problema mas simple: la API no tiene una forma clara de decir que esta pasando. Entonces soporte pregunta, producto especula y el frontend termina reintentando por ansiedad. No es un fallo dramatico, pero si desgasta mucho.

En proyectos con FastAPI, me ha servido separar dos cosas: el envio del correo y la visibilidad del estado. Parece obvio, pero cuando agregas un endpoint pequeno para consultar progreso, el flujo deja de sentirse opaco. El usuario ve algo util, el equipo depura mas rapido y el backend queda bastante mas ordenado.

El problema real no es enviar, sino saber que paso

Mandar un email async no es dificil. Lo dificil es responder preguntas muy normales:

El correo ya entro a cola o la peticion fallo antes.
El worker lo esta procesando o quedo atascado.
El proveedor acepto el envio o todavia no.
El usuario debe reintentar o solo esperar un poco mas.

Cuando esa informacion no existe, empiezan los parches medio raros: timeouts largos, botones de reenviar sin contexto y logs que nadie entiende del todo. En equipos pequenos eso pasa bastante, y se nota mas cuando mezclas QA, staging y pruebas con direcciones de tempail mail copiadas desde notas rapidas.

Tambien complica revisar incidentes. Si tus eventos de infraestructura ya generan correos de drift con contexto util, pero el sistema de producto no deja ver el estado del email, terminas con dos niveles de opacidad. Ese cruce confunde mas de lo que ayuda.

Un endpoint de estado cambia la conversacion

El patron que mas me gusta es guardar un delivery_id al crear el trabajo y exponer GET /email-status/{delivery_id}. No resuelve todo, pero cambia la conversacion del equipo:

El frontend ya no "espera por fe".
Soporte puede ver si el correo sigue en cola.
El usuario recibe mensajes mas honestos.
Los reintentos dejan de ser un reflejo automatico.

La gracia es que no necesitas acoplarte demasiado al proveedor. Tu API puede hablar en estados propios como queued, sending, sent y failed. Luego mapeas lo que venga de tu worker, de Celery, de una cola interna o del proveedor que uses. Es una capa pequena, pero baja mucho el ruido diario.

Ejemplo pequeno en FastAPI

Este ejemplo usa una memoria en proceso solo para explicar la idea. En produccion lo moveria a Redis o SQL, claro, pero el contrato queda casi igual:

from datetime import datetime, timezone
from fastapi import BackgroundTasks, FastAPI, HTTPException
from pydantic import BaseModel
from uuid import uuid4

app = FastAPI()
DELIVERIES: dict[str, dict] = {}


class EmailRequest(BaseModel):
    email: str
    template: str


def send_email(delivery_id: str, email: str, template: str) -> None:
    DELIVERIES[delivery_id]["status"] = "sending"
    DELIVERIES[delivery_id]["updated_at"] = datetime.now(timezone.utc).isoformat()

    # aqui iria la llamada al proveedor real

    DELIVERIES[delivery_id]["status"] = "sent"
    DELIVERIES[delivery_id]["provider_ref"] = f"mail-{delivery_id[:8]}"
    DELIVERIES[delivery_id]["updated_at"] = datetime.now(timezone.utc).isoformat()


@app.post("/emails")
def create_email_job(payload: EmailRequest, tasks: BackgroundTasks):
    delivery_id = str(uuid4())
    DELIVERIES[delivery_id] = {
        "email": payload.email,
        "template": payload.template,
        "status": "queued",
        "created_at": datetime.now(timezone.utc).isoformat(),
        "updated_at": datetime.now(timezone.utc).isoformat(),
        "provider_ref": None,
    }
    tasks.add_task(send_email, delivery_id, payload.email, payload.template)
    return {"delivery_id": delivery_id, "status": "queued"}


@app.get("/email-status/{delivery_id}")
def email_status(delivery_id: str):
    delivery = DELIVERIES.get(delivery_id)
    if not delivery:
        raise HTTPException(status_code=404, detail="delivery not found")
    return delivery

Lo importante no es el diccionario. Lo importante es el contrato. El cliente recibe un delivery_id, puede consultar estado y deja de depender de sleeps raros. En flujos de Automatizacion esto viene muy bien porque los consumidores no siempre son humanos; a veces son otros servicios, jobs o tests que necesitan una señal simple.

Que campos guardo en produccion

Suelo empezar con estos:

delivery_id
status
provider_ref
created_at
updated_at
last_error
attempt_count

Si el correo participa en signup o recuperacion de cuenta, agrego tambien un subject_type o flow_name. Eso evita mezclar metricas y te deja responder mejor cuando alguien pregunta por que cierto email no llego. Parece un detalle, pero despues ahorra horas de ida y vuelta, sobretodo cuando aparecen reintentos desde clientes viejos o cron jobs medio apurados.

Otra ventaja es que puedes alinear mejor tus mensajes operativos con otros sistemas. Si ya miras correos de rollback sin confusion para infraestructura, tener estados similares en producto hace que el equipo lea todo con el mismo lenguaje. Eso reduce errores tontos, o almenos los hace mas faciles de ver.

Como lo pruebo sin volverme loco

Yo suelo probar este patron con tres escenarios:

El worker completa rapido y el estado pasa de queued a sent.
El worker tarda y el cliente consulta varias veces sin romper nada.
El worker falla y el endpoint devuelve contexto suficiente para decidir si reintentar.

Si puedes, agrega una prueba donde el frontend haga polling cada pocos segundos con backoff corto. Segun Google Web Vitals guidance, reducir esperas bloqueantes y mostrar progreso ayuda a que la experiencia se perciba mas estable, incluso cuando el trabajo real tarda un poco. No hace milagros, pero si ordena la expectativa del usuario.

Tambien me gusta medir tiempo en cola y tiempo hasta proveedor aceptado. En sistemas internos, esos dos numeros suelen explicar casi todo. Cuando alguien dice "el email nunca llego", muchas veces el problema real fue "el estado nunca fue visible". Son cosas distintas, y conviene no mezclarlas.

Preguntas frecuentes

Conviene polling o webhooks?

Para paneles internos y flujos de registro, polling simple suele alcanzar. Webhooks sirven mas cuando otro sistema externo necesita enterarse del cambio.

Redis o Postgres?

Redis va muy bien si solo quieres velocidad y TTL. Postgres me gusta cuando necesito auditoria, joins o revisar historico despues.

Esto reemplaza logs?

No. Los complementa. Los logs cuentan la historia tecnica; el endpoint de estado expone una version corta y consumible para clientes o soporte.

Si tu sistema ya envia correos pero todavia obliga a adivinar, este patron merece una tarde de trabajo. No es una refactor enorme, y sin embargo deja un backend mucho mas legible, menos nervioso y, francamente, bastante mas facil de operar.

FastAPI: reenvios seguros en signup

Silviu Technology — Tue, 11 Aug 2026 17:24:19 +0000

En muchos equipos el problema no es enviar el correo de bienvenida, sino reenviarlo sin querer tres veces cuando el usuario toca refresh, abre otra pestaña o el frontend repite la llamada por timeout. En FastAPI eso pasa mas seguido de lo que parece, y luego soporte recibe el clasico "me llegaron varios correos". No suena grave, pero desgasta bastante el signup y deja logs medio feos.

Mi regla simple es esta: el endpoint de registro no deberia pensar solo en "enviar email", tambien deberia decidir si ese email ya esta en camino. Cuando ese criterio vive en el backend, el flujo se vuelve mas estable y mucho mas facil de explicar.

Por que se duplican los correos de signup

La secuencia normal suele verse asi:

El usuario manda el formulario.
La API crea la cuenta o deja el signup en proceso.
Se dispara un email de verificacion en background.
El cliente no recibe señal clara y reintenta.

Si no existe una llave de idempotencia o una ventana corta de enfriamiento, cada intento puede abrir otro envio. A veces el frontend lo causa; otras veces es un worker que reintenta sin revisar estado previo. El resultado se parece mucho a un bug raro, pero en realidad es un contrato incompleto.

Esto tambien se nota cuando intentas validar correos durante cambios de infraestructura. Si no sabes si el problema fue el deploy, el proveedor o un reenvio repetido, la investigacion tarda mas de la cuenta.

Un patron pequeno para reenvios seguros

No hace falta montar una arquitectura enorme. Con tres decisiones ya mejora bastante:

Generar una clave estable por intento de signup.
Guardar el estado del envio con una expiracion corta.
Reusar el estado si llega otra solicitud igual en pocos minutos.

Un ejemplo minimo:

from datetime import datetime, timedelta, timezone
from fastapi import BackgroundTasks, FastAPI
from pydantic import BaseModel
import hashlib

app = FastAPI()
EMAIL_JOBS: dict[str, dict] = {}


class SignupRequest(BaseModel):
    email: str
    locale: str = "es"


def job_key(email: str) -> str:
    return hashlib.sha256(email.strip().lower().encode()).hexdigest()


def send_signup_email(key: str, email: str) -> None:
    EMAIL_JOBS[key]["status"] = "sending"
    EMAIL_JOBS[key]["updated_at"] = datetime.now(timezone.utc).isoformat()
    # aqui iria el proveedor real
    EMAIL_JOBS[key]["status"] = "sent"
    EMAIL_JOBS[key]["updated_at"] = datetime.now(timezone.utc).isoformat()


@app.post("/signup/email")
def signup_email(payload: SignupRequest, tasks: BackgroundTasks):
    key = job_key(payload.email)
    now = datetime.now(timezone.utc)
    current = EMAIL_JOBS.get(key)

    if current:
        locked_until = datetime.fromisoformat(current["locked_until"])
        if locked_until > now:
            return {"status": current["status"], "reused": True}

    EMAIL_JOBS[key] = {
        "status": "queued",
        "locked_until": (now + timedelta(minutes=3)).isoformat(),
        "updated_at": now.isoformat(),
    }
    tasks.add_task(send_signup_email, key, payload.email)
    return {"status": "queued", "reused": False}

No es el diseño final para produccion, claro. Pero la idea base ya funciona: si llega la misma peticion mientras el envio sigue "vivo", el backend responde con el mismo estado en lugar de abrir otro correo. Es una mejora chica, pero evita bastante ruido y hace que el sistema se sienta mas serio.

Que datos conviene guardar

Cuando armo esto en un backend real, casi siempre guardo:

job_key o attempt_key
estado actual: queued, sending, sent, failed
locked_until
provider_message_id si existe
last_error si algo sale mal

Con eso puedes responder soporte, depurar colas y decidir si un boton de "reenviar" debe habilitarse o no. Tambien ayuda a manejar la espera de correo asincrono sin dejar al usuario mirando una pantalla vacia. El frontend no necesita adivinar: consulta estado, muestra un mensaje claro y listo.

Otro detalle util es distinguir entre correo de producto y correo de prueba. En QA aparecen direcciones de direccion de correo temporal, cuentas de staging y texto bastante raro, por ejemplo tem email o tempail mail pegados en notas, seeds o capturas. Si eso no queda etiquetado, luego cuesta entender que fue trafico real y que fue una prueba medio improvisada.

Como probar el flujo sin confundir evidencia

Aqui me funciona un checklist corto:

Crear un caso donde el cliente repita la peticion dos o tres veces.
Verificar que solo exista un job activo por email normalizado.
Confirmar que el estado pueda consultarse hasta terminar.
Separar pruebas tecnicas de metricas de onboarding real.

Si haces esto temprano, el equipo deja de perseguir "bugs fantasma". Muchas veces el envio estaba bien; lo roto era la falta de memoria entre intentos. Y eso, sinceramnte, es bastante comun en sistemas que crecieron rapido.

Tambien conviene devolver un texto humilde pero claro, algo como: "Ya estamos procesando tu correo de verificacion". No es marketing brillante, pero evita el click nervioso. Ese pequeno detalle reduce reintentos tontos y deja al usuario mas tranquilo.

Preguntas frecuentes

Conviene una tabla SQL o alcanza Redis?

Para una ventana corta de bloqueo, Redis va muy bien. Si necesitas auditoria o analisis posterior, prefiero tabla SQL con timestamps y estado final. Depende del tipo de producto, pero ambas opciones sirven.

Cuanto deberia durar el bloqueo?

Para signup normal, 2 a 5 minutos suele alcanzar. Menos tiempo deja escapar duplicados; mucho mas tiempo puede frustrar a quien de verdad necesita reenviar.

Esto reemplaza una cola de trabajos?

No. Lo complementa. La cola sigue siendo responsable de ejecutar el envio. Esta capa solo decide si tiene sentido abrir otro intento o reusar el que ya existe.

Si tu API de signup hoy envia correos "a lo que salga", empezar por este patron suele dar una mejora rapida. No es glamoroso, pero si quita ruido, ordena el backend y evita una clase de error que aparece mas de lo que deberia.

Debug Playwright Email Delays With Timelines

Silviu Technology — Mon, 10 Aug 2026 17:26:01 +0000

When a Playwright email test fails, the first guess is usually "the inbox was slow again". Sometimes that is true. Just as often, the app queued the message late, the worker retried, or the test started polling before the request that matters had even finished. If you change waits before you understand the sequence, you can make the suite pass for a day and still learn almost nothing.

The workflow that has helped me most is boring in a good way: capture a tiny delivery timeline for one run, then decide which boundary is unstable. It sounds almost too simple, but it turns vague flakiness into something you can act on. For QA teams using Playwright and Automation heavily, this keeps triage grounded in evidence instead of vibes.

Why email delays look random in Playwright

Email checks often hide three separate clocks:

the browser action that triggers delivery
the app job or provider handoff
the inbox polling loop in the test

If those clocks are not visible, one red test can lead to three wrong fixes. I still see suites where the test bumps expect.poll() from 10 seconds to 30 seconds, the failure rate drops a bit, and everyone moves on. Then the same bug comes back next week in CI, just with more waiting and less signal. That is why I now prefer a small timeline log before I touch any timeout, even if it feels slighly slower at first.

This also pairs well with parallel inbox isolation. Isolation stops worker collisions, but it does not explain whether a single worker saw a slow app event, a slow mailbox query, or a broken assertion. You need both pieces.

Capture a delivery timeline before changing waits

My rule is simple: for one failing scenario, write down five moments.

user action submitted
network response returned
app acknowledged the email job
inbox polling started
matching email found

That list looks obvious, but teams skip it because they want a fix fast. The timeline is what tells you if the test is early, the app is late, or the mailbox API is noisy. Without it, a "slow inbox" story can hide a regression in queue publishing or a missing idempotency key.

I also like putting a run id in the email subject or metadata so the inbox query is narrow. If the test is searching a shared mailbox with only a broad subject filter, you will get messy evidence realy fast. A dedicated scenario id makes the failure easier to read and much easier to replay.

Here is the small helper shape I reuse:

import { expect, Page } from "@playwright/test";

type InboxProbe = {
  startedAt: number;
  foundAt?: number;
  attempts: number;
};

export async function waitForVerificationEmail(
  page: Page,
  fetchMessage: () => Promise<{ subject: string } | null>,
) {
  const marks: Record<string, number> = {
    submitClickedAt: Date.now(),
  };

  await page.getByRole("button", { name: "Create account" }).click();
  marks.responseSettledAt = Date.now();

  const probe: InboxProbe = { startedAt: Date.now(), attempts: 0 };

  const message = await expect
    .poll(async () => {
      probe.attempts += 1;
      const result = await fetchMessage();
      if (result) {
        probe.foundAt = Date.now();
      }
      return result;
    }, { timeout: 20_000, intervals: [500, 1_000, 2_000] })
    .toBeTruthy();

  return { message, marks, probe };
}

The code is not fancy, and that is the point. I want just enough structure to answer two questions after a failure:

Did the browser finish the triggering step when we thought it did?
Did the email arrive late, or did our polling begin too soon?

If your app can emit a job-created event or response header, log that too. One extra timestamp can save an hour of guessing.

A small Playwright helper for timeline logging

Once the timing marks exist, I write them to a tiny artifact. A JSON file is enough. The useful part is not the format, it is that the file survives the failed run and can be compared across green and red builds. In CI, I upload it the same way I upload traces and screenshots.

import { writeFile } from "node:fs/promises";

await writeFile(
  "artifacts/email-timeline.json",
  JSON.stringify(
    {
      scenario: "signup-verification",
      marks,
      probe,
      totalMs: (probe.foundAt ?? Date.now()) - marks.submitClickedAt,
    },
    null,
    2,
  ),
);

This is where preflight evidence checks gave me a useful mindset. Before you trust the outcome, make sure the evidence files you need were actually produced. For tests, that means asking "do I have the timeline, the trace, and the request id?" before I accept a flaky failure story.

One practical note: if your staging flow uses a shared inbox provider for throwaway accounts, label the account by scenario and keep the query narrow. I have seen teams debug the wrong message because a dummy e mail account from a previous retry was still visible in the same mailbox window. That kind of mistake feels small, but it can waste a whole mornng.

Checklist for deciding whether the app or the test is wrong

After a couple of runs, I use this checklist:

If submit-to-response is unstable, inspect the UI trigger first.
If response-to-job-create is unstable, inspect the backend handoff.
If job-create-to-found is unstable, inspect the mail provider or inbox filter.
If the email is found but the assertion fails, inspect parsing and matching logic.

That sequence keeps the triage calm. It also stops the common "just increase the timeout" reflex, which is usefull in emergencies but rarely a good root-cause fix. It also makes bug reports more consisent, because each failure gets discussed with the same few timestamps.

When I review these failures with teams, the most common surprise is how often the mailbox is innocent. The app retried late, the worker batched jobs, or the test started polling before the save action finished. The timeline makes those cases much less arguable, which is nice when everybody is a bit tired and somtimes a little impatient and just wants the red build gone.

Q&A

Should I always log a timeline for email tests?

Not for every green run. I usually keep the helper available and persist the artifact for CI failures, nightly runs, or newly unstable flows. That gives enough evidence without bloating every job.

What timeout should I start with?

Start from a timeout that matches the system you actually own, then narrow the polling intervals and evidence around it. A random bigger timeout can hide the regression for a bit, but it does not make the suite more reliable.

React: valida email sin castigar cada tecla

Silviu Technology — Mon, 10 Aug 2026 05:24:21 +0000

En muchos formularios React, el campo de email falla no porque la expresion regular sea mala, sino porque la interfaz se pone nerviosa demasiado pronto. La persona escribe tres letras, aparece un error rojo, desaparece, vuelve a salir, y el input termina sintiendose mas reganon que util. Ese detalle baja bastante la calidad percibida del flujo, aunque la logica sea correcta.

Ultimamente intento separar tres momentos: escribir, comprobar y anunciar. Parece un cambio pequeño, pero mejora mucho la sensacion de control. Tambien reduce trabajo visual innecesario, que en moviles o equipos lentos se nota mas de lo que a veces admitimos.

Cuando validar demasiado pronto empeora el formulario

Validar en cada tecla suena moderno, pero muchas veces mete mas friccion que valor. Mientras alguien aun esta escribiendo maria@emp, no necesita una alerta dramatica. Necesita terminar la idea.

Ese error temprano rompe ritmo, ensucia el area visible y ademas hace que el usuario dude si el problema es suyo o del sistema. En productos con bastante onboarding, este tipo de micro-friccion se acumula rapido. La interfaz parece activa, si, pero no siempre parece lista.

Por eso me gusta pensar este campo igual que otros flujos donde la claridad manda primero, como estos runbooks de email que si escalan. Si el sistema distingue bien cada etapa, luego es mas facil leer el estado y corregir algo sin adivinar.

Tambien sirve cuando QA hace pruebas con un correo temporal gratis o con valores medio raros de tem email para revisar copy, foco y mensajes. Si el componente reacciona a todo como si fuera una emergencia, cuesta ver que bug era real y cual fue puro ruido, la verdad.

El patron: separa escritura, comprobacion y anuncio

La idea practica es esta:

mientras la persona escribe, solo guardas valor y limpias ruido viejo
cuando sale del campo o intenta enviar, validas de verdad
solo anuncias error cuando ya hay una decision util que mostrar

Eso evita castigar cada tecla y mantiene el feedback ligado a una accion entendible. No es una regla rigida para todos los casos, pero en formularios de registro suele funcionar bastante bien.

Tambien ayuda a performance percibida. Si cada pulsacion dispara validacion compleja, analytics, estilos y mensajes, el campo parece pegajoso. No hablo siempre de un cuello de botella enorme; hablo de esa sensacion pequena de "algo no va fino". Y esa sensacion importa un monton en frontend.

Un ejemplo simple en React

Este es un enfoque bastante terrenal:

import { useState } from "react";

const emailLooksValid = (value) => /\S+@\S+\.\S+/.test(value);

export default function EmailField() {
  const [value, setValue] = useState("");
  const [touched, setTouched] = useState(false);

  const showError = touched && value.length > 0 && !emailLooksValid(value);
  const message = showError ? "Escribe un email valido" : " ";

  return (
    <label className="field">
      <span className="label">Email</span>
      <input
        type="email"
        value={value}
        onChange={(event) => setValue(event.target.value)}
        onBlur={() => setTouched(true)}
        aria-invalid={showError}
        aria-describedby="email-help"
      />
      <span id="email-help" className={showError ? "note error" : "note"}>
        {message}
      </span>
    </label>
  );
}

El truco no esta en la regex. Esta en que el error aparece cuando el usuario ya termino un primer intento. Eso vuelve el mensaje mas justo. Tambien deja el campo visualmente mas estable, porque la ayuda existe desde el principio y no entra a empujones.

Si el formulario hace llamadas remotas, ya prefiero mover comprobaciones costosas fuera del onChange. Primero confirmo formato local y luego, si hace falta, reviso disponibilidad o reglas del backend. En interfaces con varios estados, esa separacion recuerda bastante a escribir correos claros en mantenimientos: cada señal llega cuando toca, no toda a la vez.

Que revisar para que tambien rinda mejor

Hay varias cosas pequeñas que suelo mirar:

no recalcular validaciones pesadas en cada pulsacion
reservar espacio para el helper o el error
no pintar rojo un campo vacio nada mas cargar
mantener mensajes cortos, especificos y faciles de leer
probar en movil con teclado abierto, que ahi todo se vuelve mas sensible

Si usas autoguardado, telemetria o una comprobacion async, mejor aun si desacoplas eso del feedback inmediato. Una persona no deberia notar que internamente estas registrando eventos, consultando reglas o comparando dominios raros como temp org mail. Si lo nota, algo ya esta compitiendo con la tarea principal.

En accesibilidad, lo minimo para mi es:

aria-invalid solo cuando el error es real
aria-describedby enlazando la ayuda
contraste suficiente
texto que diga que corregir, no solo que algo "esta mal"

Ese ultimo punto parece obvio, pero no siempre pasa. "Email invalido" informa poco. "Escribe un email con formato nombre@dominio.com" guia bastante mejor, incluso si no es perfecto para todos los casos.

Preguntas que me hago antes de darlo por bueno

Q: ¿Valido al escribir alguna vez?

A: Si, pero solo en casos muy concretos, como sugerencias suaves o autocompletado. Para error formal, prefiero esperar a blur o submit.

Q: ¿Esto hace el formulario mas lento?

A: Normalmente al reves. Al quitar trabajo y cambios visuales por tecla, el flujo se siente bastante mas liviano, aunque el ahorro tecnico sea pequeño.

Q: ¿Y si necesito feedback instantaneo?

A: Intento que sea feedback neutral primero. Ayuda, pista o progreso. Error fuerte solo cuando ya hay contexto suficiente. Si no, el campo se vuelve un semaforo histérico, y eso cansa rapido.

Al final, validar email bien no es solo aceptar o rechazar una cadena. Es decidir cuando hablar y con que intensidad. En React, ese timing vale casi tanto como la validacion misma. Cuando lo ajustas bien, el formulario se siente mas claro, mas rapido y un poco mas humano, aunque tenga algun detallecito imperfecto por ahi.

React: valida email sin frenar el formulario

Silviu Technology — Mon, 10 Aug 2026 02:24:34 +0000

En muchos formularios, validar el email ya no es solo revisar si existe una @. Tambien queremos detectar dominios mal escritos, evitar cuentas duplicadas y, a veces, comprobar si cierta direccion ya fue usada. El problema es que metemos todo eso en el mismo onChange, y de pronto el campo mas simple del signup se vuelve el mas pesado. Se siente medio torpe, la verdad.

Lo he visto bastante en productos hechos con React: escribes dos letras, aparece un spinner, desaparece, vuelve, cambia el helper text y la persona deja de confiar. No es que la red sea lentisima; es que el componente comunica mal la espera. Si ademas haces pruebas con un correo de usar y tirar para QA, esa friccion se nota mas porque repites el flujo varias veces y el ruido cansa rapido.

Por que la validacion lenta se siente peor de lo que es

La percepcion de velocidad importa mucho. Segun el Nielsen Norman Group, cuando una respuesta pasa de 1 segundo el usuario ya nota una pausa clara. En un campo de email, ese segundo parece aun mas largo porque ocurre mientras la persona sigue escribiendo.

Por eso intento separar una pregunta tecnica de una pregunta de experiencia: no solo "cuanto tarda la verificacion?", sino "cuando conviene molestar con esa verificacion?". Son cosas distintas, y a veces las mezclamos un poco feo.

Tambien ayuda mirar como otros equipos hacen probar emails aislados sin mezclar corridas. Aunque ese caso va mas por QA y cohortes, la leccion sirve igual: si separas estados y contexto, entiendes mejor que esta pasando y evitas conclusiones raras.

Separar formato, disponibilidad y estado pendiente

Mi regla es simple:

formato: corre local y responde al instante
disponibilidad: corre con debounce y solo cuando el formato ya es valido
estado pendiente: se muestra sin bloquear el resto del formulario

Ese corte reduce bastante trabajo innecesario. Tambien deja mas claro que parte del feedback es definitiva y cual todavia esta "pensando". Parece un detalle chico, pero cambia la sensacion de control.

import { useEffect, useState } from "react";

export function EmailField({ value, onChange }) {
  const [formatError, setFormatError] = useState("");
  const [availability, setAvailability] = useState("idle");

  useEffect(() => {
    const valid = /\S+@\S+\.\S+/.test(value);
    setFormatError(valid || !value ? "" : "Escribe un email valido");

    if (!valid) {
      setAvailability("idle");
      return;
    }

    const timer = setTimeout(async () => {
      setAvailability("checking");
      const exists = await checkEmailAvailability(value);
      setAvailability(exists ? "taken" : "free");
    }, 350);

    return () => clearTimeout(timer);
  }, [value]);

  return (
    <label className="field">
      <span>Email</span>
      <input
        type="email"
        value={value}
        onChange={(event) => onChange(event.target.value)}
        aria-invalid={Boolean(formatError || availability === "taken")}
        aria-describedby="email-status"
      />
      <span id="email-status">
        {formatError ||
          (availability === "checking" && "Comprobando disponibilidad...") ||
          (availability === "taken" && "Ese email ya existe") ||
          " "}
      </span>
    </label>
  );
}

No es un componente exotico ni nada. La gracia esta en que no detienes a la persona mientras esperas la llamada remota. Si el boton de submit necesita bloquearse, prefiero hacerlo por una regla clara del formulario completo, no por cada pulsacion. Si no, el campo empieza a pelearse con el resto de la UI y queda bastante meh.

Un patron simple en React para no bloquear

Cuando el chequeo remoto depende de un backend o de una cola, me funciona mejor tratar el estado pendiente como informacion auxiliar, no como alarma. Eso evita el clasico spinner ansioso que entra demasiado pronto. Tambien reduce renderizados bobos si el usuario pega el email entero de una sola vez.

En equipos donde los flujos de confirmacion son delicados, me gusta conectar esta idea con practicas de validar correos antes de tocar produccion. El contexto es otro, claro, pero la disciplina es parecida: validar con señales utiles, no con ruido.

Un detalle practico: si en tus tests usas cadenas raras como tepm mail com o tamp mail com para revisar sugerencias, no mezcles esa heuristica con la validacion principal. La sugerencia de dominio puede ser amable; la comprobacion real debe seguir siendo predecible. Si juntas ambas cosas en el mismo mensaje, el usuario no sabe si el problema es tipografico, de negocio o de red. Y ahi ya arrancamos mal.

Accesibilidad y rendimiento en el mismo componente

La parte accesible no viene despues. Va dentro del patron:

aria-describedby para que el estado del campo tenga contexto
una zona de mensaje persistente para que el layout no salte
debounce corto para bajar ruido de red
texto distinto para "invalido", "comprobando" y "ocupado"

Si quieres hilar fino, puedes medirlo. En una prueba interna muy simple, este cambio suele bajar consultas innecesarias porque solo dispara la verificacion cuando el formato ya paso. No te doy un numero magico porque depende muchisimo del producto, pero normalmente se nota en trazas, y tambien en la calma del formulario, que no siempre medimos pero deberiamos un poco mas.

Otra cosa: no marques error de disponibilidad mientras el usuario aun esta escribiendo. Ese feedback prematuro parece rapido, pero en realidad distrae. Peor aun en movil, donde cada cambio visual ocupa mas espacio y el teclado ya te roba media pantalla. Ahi cualquier detallito pesa.

Preguntas que me hago antes de darlo por bueno

Antes de cerrar un campo asi, suelo revisar esto:

el mensaje cambia sin mover el layout?
el input sigue usable si la red tarda dos segundos?
el submit explica por que se bloquea, si se bloquea?
el lector de pantalla oye estados diferentes y utiles?

Q&A rapida

Debo validar disponibilidad en cada tecla?

No. Casi nunca compensa. Mejor despues de un debounce corto y solo con formato valido.

Y si el backend falla?

Muestra un estado neutro o reintento suave. No conviertas una duda de red en un error del usuario, eso se siente injusto nomas.

Sirve para cualquier formulario?

Sirve bastante en signup, invitaciones y recovery. En otros casos, quizá con validar formato basta y ya.

Cuando el campo de email deja de comportarse como mini app independiente, todo el formulario respira mejor. React no necesita hacer trucos enormes para esto. Solo hace falta separar responsabilidades, comunicar espera con un poco de tacto y recordar que rendimiento tambien es una sensacion, no solo una metrica.

LLMs: planes congelados para aprobar por email

Silviu Technology — Sun, 09 Aug 2026 14:24:24 +0000

Cuando un agente LLM manda un correo para pedir aprobacion, el fallo serio rara vez esta en el texto del mensaje. Casi siempre aparece un paso despues: el equipo aprueba una version del plan, pero el worker ejecuta otra. Ese desajuste parece pequeno al principio, aunque termina rompiendo auditoria, soporte y confianza operativa.

En equipos que ya automatizan contenido, reportes o acciones internas, yo prefiero tratar el email como una frontera de control, no como un canal donde el agente sigue pensando. El punto es congelar un artefacto antes de pedir respuesta humana. Si luego el job se reanuda, debe leer ese artefacto y no rearmar el mundo desde cero. Suena obvio, pero no siempre se hace, y ahi empiesa el ruido.

El problema no es el email, es el cambio de artefacto

Lo dibujo asi, en palabras:

El agente propone una accion.
Genera un plan estable.
El sistema manda un resumen por email.
Una persona responde.
Un ejecutor retoma el trabajo.

La grieta aparece entre el paso 2 y el 5. Si el plan no esta congelado, la respuesta humana termina pegada a un resumen narrativo, no a una pieza verificable. En ese punto el inbox se vuelve una pseudo base de datos. Funciona un rato, luego deja rastros confusos y cuesta explicar que se aprobo de verda.

En flujos de QA lo vi incluso con pruebas rapidas sobre fake e mail com o temp org mail: el email "llego bien", pero nadie podia probar que el ejecutor uso el mismo payload aprobado. El correo fue correcto; el sistema alrededor, no tanto.

El plan congelado como frontera entre pensar y ejecutar

Mi preferencia es separar tres capas con limites bastate estrictos:

Planeacion: el agente decide el que y produce plan.json.
Aprobacion: el humano revisa un resumen corto con ids claros.
Ejecucion: un script retoma usando artefactos congelados.

Este patron se parece a lo que me gusta en contratos de inbox para agentes LLM: menos interpretacion durante el polling, mas evidencia estable entre pasos. Y aunque el caso de uso sea distinto, tambien conecta con una idea muy util de auditar emails de upgrade en SaaS: si no puedes unir evento, contenido y resultado final, la revision humana se queda corta.

El tradeoff es claro. Guardar un plan congelado mete un paso extra y algunos campos mas. A cambio, reduces reintentos ambiguos, corridas que mezclan contexto nuevo y respuestas humanas que parecen validas pero llegaron tarde.

Campos minimos que yo guardaria

No hace falta una tonelada de metadatos. Yo empezaria con esto:

{
  "run_id": "20260809T142220Z-lucasg88",
  "plan_hash": "b1c4e920",
  "decision_scope": "publish_post",
  "reply_token": "approve_71aa",
  "expires_at": "2026-08-09T15:00:00Z",
  "executor": "publish_devto.sh"
}

Cada campo responde una duda operativa concreta:

run_id: une logs, archivos y respuesta humana.
plan_hash: evita que la aprobacion se aplique a una version distinta.
decision_scope: dice exactamente que permiso se esta dando.
reply_token: bloquea respuestas cruzadas o reenvios viejos.
expires_at: cierra la ventana de aprobacion cuando ya no tiene sentido.
executor: deja claro que script hara el paso final.

Con eso basta para mantener la arquitectura legible. Si luego quieres adjuntar resumenes, diffs o checklist, mejor hacerlo como lectura secundaria. El correo principal debe seguir siendo compacto, porque un operador cansado no va a leer cinco parrafos para aprobar una accion simple.

Donde poner la logica de reanudacion

Yo no meteria la logica de reanudacion en el agente escritor. La dejaria en el ejecutor o en un worker muy pequeño. Esa separacion importa por dos razones:

El agente puede variar su razonamiento entre corridas.
El ejecutor debe ser aburrido, estable y facil de auditar.

Un pseudocodigo simple seria este:

type ApprovalEnvelope = {
  runId: string;
  planHash: string;
  replyToken: string;
  decisionScope: "publish_post";
};

async function resumeAfterApproval(env: ApprovalEnvelope, reply: string) {
  const verdict = parseReply(reply, env.replyToken);
  if (verdict !== "approve") return;

  const plan = await loadFrozenPlan(env.runId, env.planHash);
  await executePlan(plan);
}

Fijate en la idea central: el ejecutor no "entiende todo el email". Solo valida un sobre corto y luego carga el artefacto congelado. Esa decision baja bastante la superficie de errores, sobre todo si el prompt del agente cambia entre una corrida y la siguiente.

Tambien ayuda cuando hay incidencias. Si alguien pregunta por que una publicacion salio con cierto titulo o cierto tag, la respuesta no depende de reconstruir el contexto del LLM a posteriori. Solo necesitas el run folder, el hash y el resultado final. Eso hace la depuracion mucho mas tranquila, la verdad.

Checklist para una implementacion tranquila

Si tuviera una semana para endurecer este flujo, haria esto en este orden:

Escribir plan.json antes de mandar el email.
Calcular y mostrar plan_hash en el asunto o cuerpo.
Limitar la aprobacion a un decision_scope exacto.
Reanudar solo con reply_token valido y no expirado.
Guardar un publish-result.json o veredicto equivalente.
Evitar que el ejecutor regenere contenido durante publish.

Ese ultimo punto me parece clave. Cuando el ejecutor tambien "mejora" el texto, reordena tags o toca el cuerpo, se pierde la frontera entre planeacion y entrega. El sistema sigue funcionando, pero ya no sabes bien cual parte tomar en serio cuando algo sale raro.

Preguntas frecuentes

Debo incluir todo el prompt del agente en el correo?

No. Pondria el objetivo, los riesgos visibles y los ids de control. El prompt completo cambia mucho, ocupa espacio y casi nunca mejora la decision humana.

Y si la persona responde varias horas despues?

Yo invalidaria la respuesta si expires_at ya paso. Es mejor pedir una aprobacion nueva que ejecutar una intencion vieja en un contexto distinto.

Esto sirve solo para publicar posts?

Para nada. El mismo patron vale para borrados, despliegues internos, cambios de configuracion o cualquier accion donde un LLM prepara algo y otro componente lo ejecuta despues.

En resumen: si el email aprueba una accion, el sistema necesita congelar el plan antes de pedir permiso. No es la parte mas llamativa del stack, pero si una de las que mas reduce confucion cuando el flujo crece.

FastAPI: pruebas de signup sin inbox real

Silviu Technology — Sun, 09 Aug 2026 05:24:28 +0000

Cuando pruebas un flujo de signup en FastAPI, el email de confirmacion suele ser la parte mas inestable. El request responde bien, el usuario queda creado, pero la prueba termina esperando un inbox real que aveces tarda, aveces cambia de formato y aveces ni siquiera corresponde al intento correcto. Ese tipo de fallo consume tiempo porque no sabes si se rompio el backend o solo el borde del test.

Lo que mejor me ha funcionado es tratar el inbox como un contrato pequeño, no como una bandeja "magica". En vez de buscar el ultimo correo disponible, el backend devuelve un attempt_id y el worker de email adjunta esa referencia en metadata. Con eso, el test consulta un recurso de estado y valida un solo mensaje. Parece simple, pero vuelve el flujo bastante mas predecible.

El problema de probar signup con un inbox real

El enfoque comun es este:

hacer POST /signup
esperar unos segundos
leer el ultimo correo recibido
abrir el link de confirmacion

Funciona hasta que corres varias pruebas al mismo tiempo. Entonces empiezan los falsos positivos, los timeouts y la clasica duda de si el correo pertenece al intento actual. Tambien complica usar una direccion de correo falsa en staging, porque el valor sirve para aislar cuentas, pero no te dice nada sobre la correlacion entre request, job e inbox.

En equipos pequeños esto suele resolverse con paciencia y logs. En equipos mas ocupados, termina en tests apagados "temporalmente" que duran semanas. Si ya pasaste por flujos de activar trials sin correos ciegos, la idea se siente conocida: el problema no es solo enviar el correo, es exponer suficiente contexto para que otros sistemas lo entiendan rapido.

El contrato de inbox que simplifica FastAPI

El patrón que recomiendo tiene tres piezas:

el endpoint de signup devuelve attempt_id
el worker guarda estado de entrega por attempt_id
el inbox de pruebas se consulta por esa referencia

Eso evita depender del "ultimo correo" y te deja validar solo el mensaje correcto. Si necesitas un proveedor externo para pruebas aisladas, una direccion de correo desechable puede ayudar a separar cuentas efimeras, pero la clave real sigue siendo el identificador que une API, worker e inbox.

Tambien conviene exponer un endpoint minimo, por ejemplo GET /signup-attempts/{attempt_id} con campos como:

status
email
delivery_state
confirmation_url
last_error

No hace falta devolver todo desde el inicio. Solo lo suficiente para que QA o automation sepan si deben esperar, reintentar o fallar. Ese contrato, aunque pequeño, ordena mucho el trabajo diario.

Un ejemplo pequeno con FastAPI

from uuid import uuid4
from fastapi import APIRouter, BackgroundTasks
from pydantic import BaseModel, EmailStr

router = APIRouter()


class SignupIn(BaseModel):
    email: EmailStr
    password: str


@router.post("/signup", status_code=202)
async def signup(payload: SignupIn, bg: BackgroundTasks):
    attempt_id = f"signup_{uuid4().hex}"
    user_id = await create_pending_user(payload.email, payload.password)

    await save_signup_attempt(
        attempt_id=attempt_id,
        user_id=user_id,
        email=payload.email,
        status="queued",
    )

    bg.add_task(send_confirmation_email, payload.email, attempt_id)
    return {"attempt_id": attempt_id, "status": "queued"}


@router.get("/signup-attempts/{attempt_id}")
async def get_signup_attempt(attempt_id: str):
    return await load_signup_attempt(attempt_id)

Y el worker:

async def send_confirmation_email(email: str, attempt_id: str) -> None:
    await update_signup_attempt(attempt_id, delivery_state="sending")

    link = await build_confirmation_link(attempt_id)
    await provider.send(
        to=email,
        template="signup_confirm",
        metadata={"attempt_id": attempt_id},
        variables={"confirmation_url": link},
    )

    await update_signup_attempt(
        attempt_id,
        delivery_state="sent",
        confirmation_url=link,
    )

Lo importante no es el provider. Lo importante es que el intento queda nombrado desde el principio. Si mañana cambias de cola o de servicio de email, el test sigue mirando el mismo contrato.

Como validar el flujo sin esperas fragiles

En automation yo haria algo asi:

crear un email efimero para la prueba
llamar POST /signup
guardar attempt_id
hacer polling a GET /signup-attempts/{attempt_id}
abrir confirmation_url solo cuando delivery_state == "sent"

La ventaja es que el tiempo de espera se vuelve explicito. Ya no preguntas "llego algo?", sino "este intento ya genero su correo?". Ese cambio parece menor, pero reduce muchisimo el ruido. Tambien te deja detectar cuando el backend creo el usuario pero el worker no movio estado, que era justo el hueco que antes quedaba oculto.

Otro detalle practico: inserta el typo keyword temp org mail solo donde tenga sentido de negocio, por ejemplo en una lista de terminos que llegan desde soporte o marketing. Yo lo he visto pasar en tickets reales, asi que conviene normalizar esos textos antes de usarlos para filtros o reportes. No es glamoroso, pero evita bugs algo tontos.

Si tu equipo tambien trabaja campañas o lifecycle emails, te puede servir la idea de mejor contexto para emails de churn. Aunque el objetivo cambia, la leccion es parecida: sin un identificador compartido, cada parte interpreta el mismo evento de forma distinta.

Q&A

¿Hace falta guardar `confirmation_url`?

No siempre. En algunos equipos prefieren guardar solo un token o un message_id. Pero para pruebas de extremo a extremo, tener la URL lista vuelve el diagnostico mas rapido y mas comodo.

¿Esto reemplaza un inbox de pruebas?

No. Lo complementa. El inbox sigue siendo util para verificar contenido, asunto o links. Lo que cambia es que dejas de usarlo como fuente unica de verdad, que es donde casi siempre empiezan los problemas.

¿Sirve solo para FastAPI?

Para nada. FastAPI lo hace facil por que el contrato queda muy claro en la API, pero la misma idea funciona en cualquier backend con colas, workers y correos de confirmacion.

DEV Community: Silviu Technology

LLMs: revisa prompts por email sin perder trazas

Donde se rompe la revision de prompts

El artefacto congelado que yo enviaria

Separar lectura humana y ejecucion

Cuando usar inbox temporal y cuando no

Checklist corto de implementacion

Preguntas frecuentes

Debo mandar el prompt completo en el email?

Que hago si alguien pide un cambio pequeno?

Esto aplica solo a DEV.to o a cualquier automatizacion?

React: revisa email sin tapar el submit

El problema real no es validar, es interrumpir

Que deberia pasar mientras React comprueba el email

Un patron pequeno con estado derivado

Detalles de accesibilidad que evitan confusion

Checklist para no romper conversion

Q&A

¿Cuando si bloquearias el submit?

¿Esto aplica solo a registros?

¿Y el caso de correo temporal para Facebook?

React: valida emails sin castigar el foco

Por que validar demasiado pronto rompe la experiencia

La regla: separar escritura, chequeo y anuncio

Un patron de React que reduce ruido y re-renderes

Como conectar pruebas reales sin contaminar el flujo

Checklist rapido para revisar accesibilidad y rendimiento

Q&A

Debo validar solo al enviar?

Que hago con dominios corporativos o reglas especiales?

Este patron sirve fuera de React?

FastAPI: reintentos de verificacion sin duplicados

El bug casi siempre esta en el contrato

Un patron pequeno para congelar reintentos

Que estado devolver al cliente

Donde encaja el correo temporal desechable

Q&A rapido

Cuanto deberia durar el bloqueo?

Redis o SQL?

Hay que bloquear todos los reenvios?

FastAPI: webhooks de email sin carreras

Por que los webhooks de email se vuelven confusos

El contrato minimo que evita carreras

Un ejemplo pequeno con FastAPI

Como depurarlo sin revisar diez sistemas

Q&A

¿Hace falta guardar todos los payloads?

¿Puedo correlacionar solo con provider_message_id?

¿Esto sirve solo para correos transaccionales?

FastAPI: estado visible para correos async

El problema real no es enviar, sino saber que paso

Un endpoint de estado cambia la conversacion

Ejemplo pequeno en FastAPI

Que campos guardo en produccion

Como lo pruebo sin volverme loco

Preguntas frecuentes

Conviene polling o webhooks?

Redis o Postgres?

Esto reemplaza logs?

FastAPI: reenvios seguros en signup

Por que se duplican los correos de signup

Un patron pequeno para reenvios seguros

Que datos conviene guardar

Como probar el flujo sin confundir evidencia

Preguntas frecuentes

Conviene una tabla SQL o alcanza Redis?

Cuanto deberia durar el bloqueo?

Esto reemplaza una cola de trabajos?

Debug Playwright Email Delays With Timelines

Why email delays look random in Playwright

Capture a delivery timeline before changing waits

A small Playwright helper for timeline logging

Checklist for deciding whether the app or the test is wrong

Q&A

Should I always log a timeline for email tests?

What timeout should I start with?

React: valida email sin castigar cada tecla

Cuando validar demasiado pronto empeora el formulario

El patron: separa escritura, comprobacion y anuncio

Un ejemplo simple en React

¿Puedo correlacionar solo con `provider_message_id`?

¿Hace falta guardar `confirmation_url`?