2.9 KiB
2.9 KiB
TASK-094-rcon-first-historical-orchestration-and-safe-fallback
Goal
Reorientar la orquestación histórica para que RCON sea la vía principal de recopilación cuando esté disponible, dejando el flujo CRCON/public-scoreboard como fallback seguro y no como camino primario permanente.
Context
Actualmente:
- existe
historical_runner - existe
rcon_historical_worker - existe locking single-writer Pero la orquestación no representa todavía una estrategia RCON-first coherente. Queremos una orquestación donde:
- la recopilación prospectiva por RCON sea la prioridad
- el refresh histórico clásico solo entre cuando RCON falle o no cubra la operación
- no haya starvation del lock por loops demasiado agresivos
- las automatizaciones sean operables en Docker sin bloquear trabajo manual innecesariamente
Steps
- Auditar:
backend/app/historical_runner.pybackend/app/historical_ingestion.pybackend/app/rcon_historical_worker.pybackend/app/writer_lock.pydocker-compose.yml
- Definir una estrategia clara:
- RCON historical capture como flujo primario
- historical_ingestion clásico como fallback
- snapshots/rebuilds alineados con esa política
- Evitar que el worker RCON monopolice el writer lock:
- revisar intervalos por defecto
- revisar duración del trabajo por loop
- revisar si conviene separar captura frecuente y rebuild menos frecuente
- Asegurar que las pasadas manuales sean razonables:
- si hay automatización activa, que el operador tenga mensajes claros
- reducir riesgo de starvation o lock ocupado permanente
- Mejorar el manejo de stale locks entre contenedores Docker si es necesario:
- no depender solo del hostname si eso da falsos locks persistentes
- mantener seguridad y evitar liberar locks válidos por error
- Ajustar
docker-compose.ymlpara que el stack quede alineado con el nuevo comportamiento por defecto. - Actualizar README/runbook:
- qué proceso captura RCON primero
- cuándo entra el fallback histórico clásico
- cómo lanzar pasadas manuales
- cómo interpretar locks ocupados
Constraints
- No eliminar el locking compartido.
- No volver al comportamiento sin coordinación de writers.
- No dejar CRCON/public-scoreboard como camino principal encubierto.
- No romper la captura prospectiva RCON ya existente.
Validation
- La automatización prioriza RCON para recopilación histórica.
- El flujo clásico entra solo como fallback.
- El lock compartido sigue funcionando.
- La operativa Docker no queda en starvation constante.
- Las pasadas manuales tienen comportamiento claro y documentado.
- README/runbook queda actualizado.
Expected Files
backend/app/historical_runner.pybackend/app/historical_ingestion.pybackend/app/rcon_historical_worker.pybackend/app/writer_lock.pydocker-compose.ymlbackend/README.md- otros archivos backend si la orquestación lo requiere