RCON model
This commit is contained in:
devRaGonSa
@@ -0,0 +1,71 @@
|
||||
# TASK-087-configurable-historical-refresh-overlap
|
||||
|
||||
## Goal
|
||||
Hacer configurable la ventana de solape del refresh historico para permitir pasadas manuales de 24h, 48h o mas sobre todos los servidores sin recurrir a un bootstrap grande innecesario.
|
||||
|
||||
## Context
|
||||
La operativa actual del historico tiene dos limites practicos:
|
||||
- el refresh incremental del historico base relee solo una ventana corta reciente
|
||||
- el worker de player-events V2 tambien corta demasiado pronto para recuperar huecos recientes de forma controlada
|
||||
|
||||
Esto complica recuperar faltantes reales de los ultimos 1-3 dias, por ejemplo cuando faltan datos desde el lunes en uno o varios servidores.
|
||||
|
||||
La solucion inmediata no es RCON historico, sino exponer una ventana de solape configurable para:
|
||||
- `historical_ingestion refresh`
|
||||
- `player_event_worker refresh`
|
||||
|
||||
## Steps
|
||||
1. Revisar el flujo actual de cutoff y solape en:
|
||||
- `backend/app/historical_ingestion.py`
|
||||
- `backend/app/historical_storage.py`
|
||||
- `backend/app/player_event_worker.py`
|
||||
- `backend/app/player_event_storage.py`
|
||||
- `backend/app/config.py`
|
||||
2. Añadir configuracion explicita para el solape temporal del refresh, manteniendo compatibilidad hacia atras:
|
||||
- `HLL_HISTORICAL_REFRESH_OVERLAP_HOURS`
|
||||
- `HLL_PLAYER_EVENT_REFRESH_OVERLAP_HOURS`
|
||||
3. Exponer tambien override por CLI en ambos comandos:
|
||||
- `python -m app.historical_ingestion refresh --overlap-hours 48`
|
||||
- `python -m app.player_event_worker refresh --overlap-hours 48`
|
||||
4. Mantener el comportamiento por defecto actual o equivalente si el operador no pasa override.
|
||||
5. Asegurar que el refresh global sin `--server` recorre los tres servidores historicos ya registrados.
|
||||
6. Documentar en README el runbook operativo para:
|
||||
- pasada manual de 48 horas
|
||||
- pasada de validacion por un solo servidor
|
||||
- recomposicion posterior de snapshots
|
||||
7. Mantener el trabajo limitado al backend y runbook operativo. No tocar UI.
|
||||
|
||||
## Files to Read First
|
||||
- `backend/README.md`
|
||||
- `backend/app/historical_ingestion.py`
|
||||
- `backend/app/historical_storage.py`
|
||||
- `backend/app/player_event_worker.py`
|
||||
- `backend/app/player_event_storage.py`
|
||||
- `backend/app/config.py`
|
||||
|
||||
## Expected Files to Modify
|
||||
- `backend/app/historical_ingestion.py`
|
||||
- `backend/app/historical_storage.py`
|
||||
- `backend/app/player_event_worker.py`
|
||||
- `backend/app/player_event_storage.py`
|
||||
- `backend/app/config.py`
|
||||
- `backend/README.md`
|
||||
|
||||
## Constraints
|
||||
- No romper el refresh incremental actual.
|
||||
- No cambiar el proveedor historico actual por defecto.
|
||||
- No tocar frontend.
|
||||
- No introducir dependencias nuevas.
|
||||
- El override por CLI debe ser opcional.
|
||||
- La ventana por defecto debe seguir siendo conservadora para no disparar coste innecesario.
|
||||
|
||||
## Validation
|
||||
- Existe soporte de configuracion/env para overlap del historico base.
|
||||
- Existe soporte de configuracion/env para overlap de player-events.
|
||||
- Existen flags CLI `--overlap-hours` en ambos comandos.
|
||||
- Una pasada manual de 48 horas queda documentada para todos los servidores.
|
||||
- El repositorio queda consistente.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 7 archivos modificados o creados.
|
||||
- Preferir menos de 260 lineas cambiadas.
|
||||
@@ -0,0 +1,70 @@
|
||||
# TASK-088-rcon-historical-ingestion-feasibility
|
||||
|
||||
## Goal
|
||||
Aterrizar con precision si la repo puede soportar una ingesta historica por RCON y, en caso afirmativo, definir una arquitectura minima, incremental y defendible sin asumir capacidades que hoy no estan probadas.
|
||||
|
||||
## Context
|
||||
La repo ya tiene:
|
||||
- proveedor live por RCON
|
||||
- seleccion de `historical_data_source`
|
||||
- placeholder `RconHistoricalDataSource`
|
||||
|
||||
Pero todavia no existe una implementacion historica real por RCON. Antes de abrir trabajo de implementacion, hace falta una auditoria tecnica que determine:
|
||||
- que datos puede dar realmente el cliente RCON actual
|
||||
- si permiten reconstruccion historica, solo captura prospectiva o solo telemetria parcial
|
||||
- que huecos deben mantenerse temporalmente en `public-scoreboard`
|
||||
- que contrato minimo puede exponerse sin vender capacidades inexistentes
|
||||
|
||||
## Steps
|
||||
1. Revisar la capa actual de seleccion de proveedores y el adapter RCON existente.
|
||||
2. Auditar el cliente RCON y documentar exactamente:
|
||||
- comandos soportados hoy
|
||||
- forma del payload disponible hoy
|
||||
- frecuencia de captura razonable
|
||||
- si hay o no base para historico real de partidas cerradas
|
||||
3. Redactar una decision tecnica clara con una de estas salidas:
|
||||
- no viable con el cliente actual
|
||||
- viable solo para captura prospectiva
|
||||
- viable para una capa historica parcial
|
||||
4. Diseñar la arquitectura minima recomendada:
|
||||
- almacenamiento
|
||||
- workers
|
||||
- checkpoints
|
||||
- compatibilidad con `public-scoreboard`
|
||||
- politica de degradacion si faltan metricas
|
||||
5. Dejar una propuesta de fases realista:
|
||||
- fase 1: captura prospectiva
|
||||
- fase 2: lectura operativa minima
|
||||
- fase 3: metricas competitivas si la senal lo permite
|
||||
6. Actualizar README para reflejar el estado real y evitar ambiguedad sobre “historico por RCON”.
|
||||
|
||||
## Files to Read First
|
||||
- `backend/README.md`
|
||||
- `backend/app/data_sources.py`
|
||||
- `backend/app/providers/rcon_provider.py`
|
||||
- `backend/app/rcon_client.py`
|
||||
- `backend/app/historical_ingestion.py`
|
||||
- `backend/app/historical_storage.py`
|
||||
- `backend/app/player_event_worker.py`
|
||||
- `backend/app/player_event_storage.py`
|
||||
|
||||
## Expected Files to Modify
|
||||
- `docs/rcon-historical-ingestion-design.md`
|
||||
- `backend/README.md`
|
||||
|
||||
## Constraints
|
||||
- No implementar aun la ingesta historica por RCON.
|
||||
- No cambiar runtime behavior del backend.
|
||||
- No tocar frontend.
|
||||
- No asumir que RCON resuelve backfill retroactivo si eso no esta demostrado.
|
||||
- Mantener el documento muy concreto y util para una implementacion posterior.
|
||||
|
||||
## Validation
|
||||
- Existe un documento de diseno con conclusion clara.
|
||||
- El README deja claro que parte esta implementada y cual no.
|
||||
- No se introducen cambios de comportamiento en produccion o desarrollo.
|
||||
- El repositorio queda consistente.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 3 archivos modificados o creados.
|
||||
- Preferir menos de 220 lineas cambiadas.
|
||||
@@ -0,0 +1,72 @@
|
||||
# TASK-089-rcon-prospective-historical-capture-foundation
|
||||
|
||||
## Goal
|
||||
Implementar una base de captura historica prospectiva por RCON que empiece a persistir datos hacia delante sin sustituir todavia `public-scoreboard` y sin prometer recuperacion retroactiva de periodos ya perdidos.
|
||||
|
||||
## Context
|
||||
Esta task depende del diseno aprobado en la task anterior.
|
||||
|
||||
El objetivo aqui no es “rehacer todo el historico por RCON” en un solo paso, sino dejar una primera capacidad operativa para recoger telemetria historica hacia delante desde los targets RCON configurados.
|
||||
|
||||
La captura debe:
|
||||
- vivir fuera del request path HTTP
|
||||
- persistir datos con trazabilidad y checkpoints
|
||||
- convivir con el historico actual basado en `public-scoreboard`
|
||||
- ser util aunque al principio no cubra todas las metricas competitivas
|
||||
|
||||
## Steps
|
||||
1. Revisar el diseno de `docs/rcon-historical-ingestion-design.md`.
|
||||
2. Crear una capa de almacenamiento propia para historico prospectivo RCON:
|
||||
- tablas o estructuras separadas del historico `historical_*` actual
|
||||
- trazabilidad por servidor, run y checkpoint
|
||||
3. Extender el cliente/provider RCON solo en la medida aprobada por el diseno:
|
||||
- sin asumir comandos no auditados
|
||||
- sin mezclar live state puntual con historico persistido
|
||||
4. Crear un worker o runner dedicado de captura prospectiva RCON.
|
||||
5. Permitir ejecucion:
|
||||
- manual de una pasada
|
||||
- periodica por bucle local o Compose
|
||||
6. Añadir configuracion explicita para:
|
||||
- targets
|
||||
- intervalo
|
||||
- reintentos
|
||||
- timeouts
|
||||
7. Añadir metadata de estado minima y runbook en README.
|
||||
8. Mantener `public-scoreboard` como fuente historica por defecto hasta que exista una capa de lectura historica RCON util.
|
||||
|
||||
## Files to Read First
|
||||
- `docs/rcon-historical-ingestion-design.md`
|
||||
- `backend/README.md`
|
||||
- `backend/app/data_sources.py`
|
||||
- `backend/app/providers/rcon_provider.py`
|
||||
- `backend/app/rcon_client.py`
|
||||
- `backend/app/config.py`
|
||||
- `docker-compose.yml`
|
||||
|
||||
## Expected Files to Modify
|
||||
- `backend/app/config.py`
|
||||
- `backend/app/data_sources.py`
|
||||
- `backend/app/providers/rcon_provider.py`
|
||||
- `backend/app/rcon_client.py`
|
||||
- uno o varios archivos nuevos bajo `backend/app/` para worker/storage/run tracking
|
||||
- `backend/README.md`
|
||||
- opcionalmente `docker-compose.yml` si conviene dejar un servicio dedicado
|
||||
|
||||
## Constraints
|
||||
- No reemplazar todavia `public-scoreboard` como fuente historica principal.
|
||||
- No tocar la UI.
|
||||
- No romper `/api/servers` live por RCON.
|
||||
- No prometer backfill retroactivo.
|
||||
- Mantener separada la telemetria prospectiva RCON del historico importado actual.
|
||||
- No introducir dependencias externas innecesarias.
|
||||
|
||||
## Validation
|
||||
- Existe una pasada manual funcional de captura prospectiva RCON.
|
||||
- Existen checkpoints o run tracking.
|
||||
- La persistencia queda separada y consistente.
|
||||
- README documenta la operativa minima.
|
||||
- La repo sigue pudiendo arrancar sin obligar a usar RCON historico.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 9 archivos modificados o creados.
|
||||
- Preferir menos de 420 lineas cambiadas.
|
||||
@@ -0,0 +1,65 @@
|
||||
# TASK-090-rcon-historical-provider-minimal-read-model
|
||||
|
||||
## Goal
|
||||
Construir una primera capa de lectura historica minima sobre la persistencia prospectiva RCON, sin intentar aun paridad completa con todos los rankings competitivos del historico actual.
|
||||
|
||||
## Context
|
||||
Esta task depende de la task anterior.
|
||||
|
||||
Una vez exista captura prospectiva RCON, hace falta una primera capa de lectura util que permita comprobar cobertura real y exponer algo operativo sin mentir sobre la profundidad disponible.
|
||||
|
||||
La prioridad aqui no es clonar toda la salida de `public-scoreboard`, sino exponer:
|
||||
- cobertura
|
||||
- actividad reciente
|
||||
- estado del historico RCON disponible
|
||||
- una base compatible para evolucion posterior
|
||||
|
||||
## Steps
|
||||
1. Implementar una primera version funcional de `RconHistoricalDataSource` basada en datos persistidos, no en consultas RCON on-demand dentro del request path.
|
||||
2. Definir un read model minimo util para:
|
||||
- resumen/cobertura por servidor
|
||||
- actividad o sesiones recientes
|
||||
- metadata de disponibilidad y frescura
|
||||
3. Exponer un camino de seleccion seguro por `HLL_BACKEND_HISTORICAL_DATA_SOURCE=rcon` sin romper el modo `public-scoreboard`.
|
||||
4. Mantener la degradacion controlada cuando falten metricas:
|
||||
- devolver payload coherente
|
||||
- documentar que contratos quedan soportados y cuales no todavia
|
||||
5. Actualizar README y runbook para aclarar:
|
||||
- que endpoints funcionan con la lectura RCON minima
|
||||
- que endpoints siguen dependiendo de `public-scoreboard`
|
||||
6. No intentar aun:
|
||||
- weekly/monthly leaderboards completos
|
||||
- MVP V1/V2 completos
|
||||
- equivalencia total con `historico.html`
|
||||
|
||||
## Files to Read First
|
||||
- `docs/rcon-historical-ingestion-design.md`
|
||||
- `backend/README.md`
|
||||
- `backend/app/data_sources.py`
|
||||
- `backend/app/payloads.py`
|
||||
- `backend/app/routes.py`
|
||||
- los archivos creados en la task anterior para captura prospectiva RCON
|
||||
|
||||
## Expected Files to Modify
|
||||
- `backend/app/data_sources.py`
|
||||
- `backend/app/payloads.py`
|
||||
- `backend/app/routes.py`
|
||||
- uno o varios archivos nuevos bajo `backend/app/` para read model RCON historico
|
||||
- `backend/README.md`
|
||||
|
||||
## Constraints
|
||||
- No sustituir aun el historico actual completo.
|
||||
- No tocar frontend.
|
||||
- No exponer contratos falsos o semicompletos como si fueran paridad total.
|
||||
- La lectura HTTP debe seguir siendo fast-path de solo lectura sobre persistencia local.
|
||||
- Si un endpoint no queda soportado por la capa minima, debe quedar documentado y degradar de forma clara.
|
||||
|
||||
## Validation
|
||||
- `HLL_BACKEND_HISTORICAL_DATA_SOURCE=rcon` deja una lectura historica minima operativa y documentada.
|
||||
- El backend no rompe el modo `public-scoreboard`.
|
||||
- La documentacion deja claro el alcance real de esta primera capa de lectura.
|
||||
- El repositorio queda consistente.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 7 archivos modificados o creados.
|
||||
- Preferir menos de 320 lineas cambiadas.
|
||||
Reference in New Issue
Block a user