Primero aclara cual es el error
HTTP 429 significa que un proveedor no aceptará otra solicitud en este momento. Esto es diferente a un token de OAuth caducado, un permiso faltante, un medio no válido o un error técnico de la plataforma. Sólo los errores correctamente clasificados reciben la reparación adecuada.
La respuesta puede contener una sugerencia de reintento posterior. Si falta, el sistema utiliza un retroceso exponencial limitado con dispersión aleatoria. Esto significa que los trabajos paralelos no se reinician al mismo tiempo y generan inmediatamente el siguiente límite.
Antes de volver a intentarlo, se debe aclarar la idempotencia.
Si se pierde la conexión, no siempre se sabe si el proveedor ya aceptó la contribución. Un reintento ciego puede publicar dos veces. Cada trabajo de publicación necesita una identificación interna estable y, si es compatible, una clave de idempotencia o una referencia del proveedor.
Si el resultado no es claro, el trabajo cambia a un estado como DESCONOCIDO o VERIFICANDO. El sistema primero verifica el estado del proveedor y las referencias existentes. Sólo podrá repetirse un intento que manifiestamente no se haya realizado.
El backoff sigue siendo limitado y observable
Un plan de reintento sensato tiene un número máximo de intentos, un tiempo de espera máximo y un final. Cada intento registra la clase de error, la hora y la próxima fecha límite. Las repeticiones interminables ocultan un defecto y pueden generar costos adicionales.
Después de agotadores intentos, la publicación no se marcará como exitosa. Permanece bloqueado o se deriva a la acción del usuario. Otras plataformas pueden seguir funcionando siempre que sus trabajos sean independientes.
- Respetar el reintento después
- Utilice backoff exponencial con fluctuación
- limitar el máximo de intentos
- no repetir si el resultado externo no está claro
- aislar por plataforma
- Hacer las reparaciones visibles al final.
No siempre es posible recurrir al proveedor
Para medios de stock o procesamiento generativo, otro proveedor aprobado puede cumplir el mismo propósito técnico. Sin embargo, con la publicación social real, la cuenta objetivo está vinculada a una conexión de plataforma. No se puede publicar un cambio sin que se note a través de otra cuenta o herramienta.
Por lo tanto, el respaldo se evalúa por tipo de acción. Una búsqueda de imágenes vacías puede cambiar a una segunda fuente calificada. Un derecho OAuth faltante requiere una reconexión. Una relación de aspecto no válida requiere un ajuste de medios.
Runbook corto para operaciones
Un equipo debe tener un proceso establecido para errores de publicación recurrentes. Reduce las reparaciones espontáneas y hace que los informes de estado sean comprensibles.
- Mostrar clase de error y canal afectado
- Verifique el estado externo y la identificación del proveedor
- determinar un reintento seguro o una acción específica del usuario
- continuar trabajos independientes
- Una vez completado, sincronice la cola y el calendario.
- Excluir duplicados entre ID internos y externos
FAQ
¿Se debe volver a intentar un 429 inmediatamente?
No. Debe esperar el aviso del proveedor o una suspensión limitada. Los reintentos paralelos instantáneos a menudo ajustan el límite.
¿Puede detenerse todo el trabajo debido a una plataforma?
Sólo si falta un requisito común relevante para la seguridad. Un error aislado en la plataforma no debería bloquear otras publicaciones independientes.