comunidadhll/ai/tasks/done/TASK-050-live-snapshot-refresh-and-frontend-polling-alignment.md

TASK-050-live-snapshot-refresh-and-frontend-polling-alignment

Goal

Alinear la captura periodica de snapshots y el consumo del frontend para que la web muestre datos mucho mas cercanos al estado real actual de los servidores, evitando que se queden estancados durante horas.

Context

La pagina ya consume datos reales A2S, pero en la practica estaba mostrando snapshots demasiado antiguos, con mapas y poblacion desactualizados. Esto degrada la percepcion de fiabilidad del producto. El sistema necesitaba una politica mas util de refresco local y una lectura periodica razonable desde frontend.

Steps

1. Revisar como se ejecuta actualmente el scheduler local de snapshots.
2. Revisar la frecuencia de captura actual o la ausencia de ejecucion continua.
3. Definir una frecuencia de refresco razonable para entorno local de desarrollo y demo, por ejemplo:
   • captura backend cada 60 segundos
   • refresco frontend cada 60-90 segundos
4. Ajustar el scheduler o su configuracion para facilitar un refresco frecuente y controlado.
5. Revisar el frontend para que vuelva a consultar el backend periodicamente sin necesidad de recargar la pagina.
6. Asegurar que el refresco no rompa la UI ni genere comportamiento agresivo.
7. Mantener el sistema simple y apropiado para la fase actual.
8. Documentar claramente como arrancar el backend y el refresco para ver datos vivos.

Files to Read First

• AGENTS.md
• ai/repo-context.md
• backend/README.md
• backend/app/config.py
• backend/app/scheduler.py
• backend/app/collector.py
• frontend/assets/js/main.js
• frontend/index.html

Expected Files to Modify

• backend/README.md
• backend/app/config.py
• backend/app/scheduler.py
• frontend/assets/js/main.js
• opcionalmente frontend/index.html si requiere una alineacion minima

Constraints

• No introducir infraestructura pesada.
• No anadir librerias nuevas.
• No hacer cambios destructivos.
• No abrir nuevas fuentes de datos.
• Mantener la solucion simple, local y util para producto actual.

Validation

• El sistema puede refrescar snapshots reales con una frecuencia razonable.
• El frontend actualiza la vista sin depender de recarga manual.
• Los mapas y jugadores cambian cuando cambian realmente en los servidores.
• La documentacion deja claro como usar este flujo en local.

Change Budget

• Preferir menos de 5 archivos modificados.
• Preferir menos de 180 lineas cambiadas.

Outcome

• backend/app/config.py baja el intervalo por defecto del scheduler local a 60 segundos para acercar la persistencia a una demo viva.
• backend/app/scheduler.py alinea la ayuda del comando con ese nuevo comportamiento orientado a desarrollo y demo.
• frontend/index.html expone data-server-refresh-ms=\"60000\" y frontend/assets/js/main.js reutiliza ese valor para relanzar hydrateServers() cada 60 segundos sin recargar la pagina y sin solapar peticiones.
• backend/README.md documenta el flujo local recomendado con backend, scheduler y polling del frontend.

Validation Result

• Validado con node --check frontend/assets/js/main.js.
• Validado con python -m py_compile backend/app/config.py backend/app/scheduler.py backend/app/collector.py.
• Revisado en diff: la task queda limitada a backend/README.md, backend/app/config.py, backend/app/scheduler.py, frontend/assets/js/main.js, frontend/index.html y este archivo de task.

Decision Notes

• Se mantuvo el polling solo sobre el bloque de servidores para no convertir toda la landing en una pagina con refresco agresivo. Salud del backend y trailer siguen siendo una hidratacion inicial simple.