Todas las guíasForense de rutas · Atribuir la ruta

Cómo impedir que un reintento de JavaScript duplique el trabajo enviado por un proxy REST

Un experimento de veinte operaciones permite asignar la responsabilidad de idempotencia a una sola capa y comprobar que un timeout incierto no se convierte en dos trabajos facturables.

Actualizado 2026-09-01 · 4 min de lectura
Escrita para
Responsable técnico de WordPress
Formato
Experimento de implantación de idempotencia
Resultado
Hoja de aceptación de envíos duplicados

Dos respuestas no son necesarias para pagar dos operaciones

Una función de inteligencia artificial (IA) puede duplicarse cuando el navegador deja de esperar, aunque el proxy REST de WordPress continúe trabajando. JavaScript interpreta el timeout como ausencia de ejecución y vuelve a enviar; el servidor acepta la segunda operación mientras la primera termina. La persona usuaria recibe una sola respuesta válida, pero el proveedor procesa dos solicitudes distintas.

Para confirmarlo, no cuente clics ni mensajes visibles. Siga una operación lógica mediante cuatro identificadores: el generado por el navegador, el de la petición REST, el del trabajo interno y el del proveedor. Una duplicación queda probada cuando una misma intención conserva el primer identificador y produce dos identificadores remotos con consumo.

La clave debe representar la intención, no cada intento de red

Genere la clave de idempotencia antes del primer envío y reutilícela en todos los reintentos de esa misma acción. Si JavaScript crea una clave nueva al reintentar, el servidor no puede saber que se trata del mismo trabajo. No derive la clave únicamente de un prompt, porque dos personas pueden solicitar legítimamente el mismo texto y una misma persona puede querer repetirlo más tarde.

Una sola capa acepta o recupera la operación

Asigne a una capa la decisión definitiva. En una integración WordPress, suele ser el endpoint que acepta el trabajo: registra de forma atómica la clave y su estado, devuelve el resultado ya existente cuando procede y evita una segunda llamada al proveedor. El proveedor puede ofrecer su propia idempotencia, pero no debe ser la única defensa si existen efectos locales antes de la llamada.

Ejecute veinte trabajos bajo fallos controlados

Prepare cinco operaciones normales, cinco con timeout del navegador antes de la respuesta, cinco con pérdida de respuesta después de que el servidor complete y cinco con dos clics rápidos. Mantenga iguales modelo, payload y límites. El resultado esperado son veinte intenciones, veinte aceptaciones REST, veinte llamadas facturables y veinte resultados recuperables, no cuarenta intentos escondidos tras veinte pantallas.

La hoja de aceptación debe registrar tanto el primer envío como cada repetición. Un reintento puede devolver 200 con el resultado previo, 202 con el trabajo aún en curso o una respuesta inequívoca de conflicto; lo importante es que no cree un segundo efecto. Defina además cuánto tiempo se conserva la clave, porque una ventana demasiado corta reabre la duplicación mientras el primer trabajo sigue activo.

CasoIntencionesSolicitudes de redLlamadas al proveedorCriterio de aceptación
Normal555Cinco resultados únicos
Timeout antes de responder5105El reintento recupera el mismo trabajo
Respuesta perdida tras completar5105No se vuelve a ejecutar
Doble clic5105Una aceptación por clave
Total203520Relación lógica 20:20:20

Trate los errores anteriores a la ejecución de forma distinta

No almacene como resultado definitivo una validación fallida que nunca inició trabajo. Distinga «rechazado antes de ejecutar», «en curso», «completado» y «estado incierto». En este último caso, el cliente consulta por la misma clave en lugar de lanzar otra operación. El registro necesita una restricción única o una transacción; una comprobación seguida de inserción sin atomicidad falla bajo concurrencia.

Tampoco cambie simultáneamente el timeout, el número de reintentos y el transporte. Primero implante la deduplicación y ejecute la matriz; después ajuste la experiencia de espera. Así podrá saber si la reducción de coste procede de una única ejecución o simplemente de que el navegador dejó de reintentar durante la prueba.

Despliegue con recuperación y una métrica que detecte regresiones

Empiece con una ruta no crítica o un porcentaje pequeño. Mida operaciones lógicas, solicitudes recibidas, claves repetidas, llamadas al proveedor y resultados sin propietario. La razón llamadas remotas/operaciones lógicas debería acercarse a 1; una razón superior indica duplicación, mientras que una inferior exige comprobar si se están fusionando solicitudes legítimamente distintas.

Lo que debe quedar documentado

Documente dónde nace la clave, quién la persiste, cuánto dura y cómo se recupera un resultado. La guía de instalación sirve para comprobar la ruta protegida, pero la idempotencia pertenece a la operación de negocio y debe funcionar incluso si cambia el control de gasto. El objetivo final no es ocultar reintentos, sino hacer que sean seguros.

Use la Hoja de aceptación de envíos duplicados de «Cómo impedir que un reintento de JavaScript duplique el trabajo enviado por un proxy REST» en una primera instalación real. Descargue AI Cost Circuit Breaker gratis, empiece en Monitoring y active el bloqueo solo después de verificar señales y reversión.

Fuentes primarias consultadas

Siguiente guíaReconstrucción total de embeddings tras una publicación masiva: mida el riesgo antes de autorizarla