Agenda reintentos webhook

Los receptores de webhooks y los trabajadores de entrega necesitan una lista explícita de tiempos de espera antes de cada reintento, no una promesa vaga de que el backoff se aplicará en algún punto de la pila. Este generador de agenda de reintentos de entrega webhook toma un número máximo de reintentos, un retardo base estrictamente positivo y una estrategia fija, lineal o exponencial, y devuelve los retardos por intento, las esperas acumuladas y una fórmula breve que usted puede fijar en pruebas o mostrar junto a un panel. La misma lógica pura se ejecuta gratis en el navegador y por la API, de modo que planificar una escalera exponencial de cinco reintentos sin conexión coincide con lo que usará su worker en el borde al configurar rutas de notificación o bucles de entrega propios. Los retardos base inválidos fallan de inmediato con invalid_input en lugar de inventar esperas nulas o negativas que saturarían una cola.

Qué es una agenda de reintentos webhook y en qué se diferencian las tres estrategias

Sin una agenda publicada, los operadores no pueden razonar sobre la latencia de entrega en el peor caso, y las pruebas de carga no reproducen los huecos exactos que un worker de producción insertará entre reintentos. El backoff fijo mantiene el mismo retardo base en cada intento: sencillo de razonar y amable con los sistemas aguas abajo que solo necesitan un breve enfriamiento. El backoff lineal multiplica el retardo base por el índice de intento (base uno), de modo que los reintentos posteriores esperan proporcionalmente más sin crecer tan rápido como la pura exponencial. Una agenda de reintentos de entrega webhook es la lista ordenada de retardos que usted espera antes del intento uno, del dos y así sucesivamente tras un POST fallido a la URL del suscriptor. Esta capacidad codifica tres familias habituales de backoff usadas en buses de mensajes y clientes HTTP. El backoff exponencial duplica el retardo anterior cada vez usando base_delay por dos elevado a intento menos uno, el patrón clásico ante fallos de red transitorios y límites de tasa. Usted suministra max_retries como cuántas ranuras de reintento materializar, base_delay como semilla positiva en la unidad elegida (normalmente milisegundos) y strategy como fixed, linear o exponential. La respuesta repite esas entradas, lista los retardos en orden, los suma como total_wait y expande un array schedule con número de intento, retardo y espera acumulada para que gráficos de UI y generadores de configuración no necesiten aritmética extra.

Contrato de entrada, forma de la respuesta y cuándo falla la validación

Envíe por POST un cuerpo JSON con tres campos obligatorios. max_retries es un entero de uno a cien que indica cuántos reintentos programar. base_delay es un número finito estrictamente mayor que cero en cualquier unidad coherente; cero y valores negativos se rechazan porque una espera no positiva o bien hace busy-spin o carece de sentido para la programación. strategy debe ser la cadena fixed, linear o exponential (sin distinguir mayúsculas tras el recorte). Se aceptan alias como retries, base_ms y backoff para que formas de configuración existentes encajen limpiamente. Campos ausentes, max_retries no enteros, base_delay no finito y estrategias desconocidas lanzan invalid_input y no se facturan. En caso de éxito el cuerpo incluye max_retries, base_delay, strategy, delays como array plano, total_wait como suma de retardos, attempt_count igual a max_retries, schedule como objetos con attempt, delay y cumulative, y formula que reexpresa la forma cerrada de la estrategia elegida. Ejemplo: max_retries cinco, base_delay mil, strategy exponential produce retardos de mil, dos mil, cuatro mil, ocho mil y dieciséis mil con total_wait de treinta y un mil. Combine la agenda con su propia política de jitter si necesita dispersión aleatoria; este endpoint omite a propósito el jitter y las marcas de tiempo de reloj de pared para que los resultados sigan siendo deterministas entre navegador y API. El tope de max_retries es cien para que un error tipográfico no expanda un payload enorme ni desborde productos intermedios en escaleras exponenciales grandes.

Dónde generar una agenda de reintentos aporta valor en sistemas reales

Los arneses de prueba de carga inyectan el mismo array de retardos que usa el worker de producción, eliminando el clásico desfase en el que el entorno de pruebas reintenta más rápido que producción y enmascara errores de límite de tasa. Las plataformas de entrega que exponen ajustes de fiabilidad de webhooks pueden invocar este generador cuando un operador elige el máximo de reintentos y un modo de backoff, y luego almacenar los retardos resultantes junto al secreto del endpoint y la clave de firma. Los runbooks de incidentes se benefician de un total_wait imprimible para que el personal de guardia sepa cuánto puede retrasarse un suscriptor inestable antes del último intento. Los generadores OpenAPI y de SDK pueden documentar escaleras de ejemplo concretas sin mantener a mano tablas que se desvíen del código en tiempo de ejecución. Como la implementación es parse puro de nivel A, cada llamada correcta cuesta el precio base publicado $0.002 sin tokens de modelo ni red de salida; la validación fallida no consume saldo. Mantenga base_delay y total_wait en la misma unidad que sus primitivas de sleep para no convertir milisegundos a segundos por error al cablear la agenda en un bucle de worker.