Cuando un bot vuelve a arrancar, la tarea que estaba ejecutando puede seguir pendiente, haberse completado o quedar en un estado incierto. Antes de reintentar, necesito distinguir esos casos. El objetivo es recuperar trabajo verificable sin repetir una acción a ciegas.
Si todavía estás eligiendo cómo arrancar y supervisar el proceso, consulta la comparativa de PM2, Supervisor y systemd. Aquí me centro en lo que ocurre con las tareas cuando ese proceso se interrumpe.
Decidir qué hacer con una tarea interrumpida
| Estado comprobado | Decisión de recuperación | Evidencia necesaria |
|---|---|---|
| No empezó la acción | Reprogramar si el intento anterior ya no puede ejecutarla. | Estado duradero y propiedad vigente de la tarea. |
| Resultado confirmado | Registrar el resultado sin volver a ejecutar la acción. | Identificador de operación y confirmación del destino. |
| Resultado incierto | Conciliar con el destino o pasar a revisión. | Consulta de estado, clave de idempotencia admitida o revisión humana. |
Ejemplo hipotético: un bot registra un envío en un sistema autorizado, pero se corta la conexión antes de guardar la respuesta. La ausencia de respuesta no demuestra que el envío haya fallado. Buscaría la operación por su identificador; si el destino no permite comprobarla ni repetirla de forma idempotente, detendría el reintento automático.
Un bloqueo local no cancela una petición remota ya enviada. La guía de colas de trabajo para bots móviles desarrolla la asignación de trabajo y dispositivos. Esta comprobación se centra en resolver el estado después de una interrupción.
Estado duradero y reintentos acotados
Coloca tareas en una cola duradera, confírmalas después de guardar estado y haz segura la repetición cuando sea posible. Guarda checkpoints fuera de memoria. Aplica reintentos limitados con backoff y revisión manual. En plataformas de terceros, opera solo con usos autorizados, límites publicados y condiciones aplicables; un reinicio nunca debe causar una avalancha de peticiones.
Parada gradual y despliegue
Al terminar, deja de aceptar trabajo, termina o libera la tarea, vacía logs y cierra conexiones. Concede un timeout realista. Despliega versiones identificables, ejecuta una prueba mínima y conserva un rollback documentado.
Errores comunes
- ejecutar bots dentro de SSH
- usar reinicios ilimitados y sin espera
- guardar estado solo en memoria
- duplicar workers para una cuenta
- reintentar acciones no idempotentes a ciegas
- ejecutar como root
- versionar secretos
- llenar el disco con logs y capturas
- medir uptime, pero no trabajo completado
Checklist práctico de producción
- usa una cuenta con mínimos privilegios
- fija rutas absolutas y directorio
- valida entorno y secretos al arrancar
- define espera, límite de reinicios y memoria
- gestiona señales y parada gradual
- usa colas, bloqueos y checkpoints duraderos
- limita y monitoriza reintentos
- rota logs y trazas
- alerta por trabajo estancado, caídas y edad de cola
- prueba reinicio, fallo de red y rollback
Monitorización de trabajo útil
Mide tareas correctas, fallos, duración, edad de cola, reintentos y tiempo desde el último resultado válido. Añade IDs de correlación sin credenciales ni datos innecesarios. Lee qué guardar en logs de bots y cómo escalar bots con seguridad.
El caso SwimUpvote muestra ejecuciones y evidencia operativa. Permite ver cómo se investiga una tarea; no demuestra que cualquier integración pueda repetir acciones sin efectos duplicados.
Preparar una revisión de recuperación
Si los reinicios repiten acciones o dejan trabajo pendiente, revisaría una tarea concreta: evento inicial, estado guardado, acción externa, confirmación y criterio de reintento. Propondría probar interrupciones antes de la acción, después de enviarla y después de confirmarla, con datos de prueba y resultados esperados acordados.
La entrega debería dejar una política de recuperación, evidencias y un responsable para los estados inciertos. Puedes consultar mis servicios de automatización o explicarme qué tarea no se recupera para acotar el trabajo.