1.8 KiB
1.8 KiB
TASK-104-landing-loading-state-and-stale-lock-hardening
Goal
Corregir dos problemas de producto/operación ya detectados:
- la landing muestra primero datos fake estáticos antes de hidratar
- los stale locks entre contenedores Docker siguen bloqueando pasadas manuales aunque los workers ya estén parados
Context
Se ha confirmado que:
- la homepage renderiza cards estáticas fake y luego las sustituye al hidratar
- eso genera un flash de datos falsos
- además, el lock compartido puede quedar huérfano entre contenedores y requiere borrado manual
Steps
- Para la landing:
- auditar
frontend/index.html,frontend/assets/js/main.js,frontend/assets/css/styles.css - aplicar la opción A:
- no mostrar cards fake iniciales
- dejar contenedor vacío o skeleton/loading state
- renderizar solo datos reales al hidratar
- degradar limpio si falla la API
- auditar
- Para el stale lock:
- auditar
backend/app/writer_lock.py - mejorar la detección/recuperación de locks huérfanos entre contenedores Docker
- no depender únicamente del hostname si eso bloquea recuperación válida
- mantener seguridad para no liberar locks activos por error
- auditar
- Documentar el comportamiento actualizado en README/runbook.
Constraints
- No rehacer la landing completa.
- No romper el single-writer lock.
- No volver al comportamiento sin coordinación.
- No introducir riesgo de liberar locks válidos sin comprobación suficiente.
Validation
- La landing ya no muestra datos fake antes de hidratar.
- Los locks huérfanos entre contenedores se recuperan mejor o quedan claramente resueltos.
- La repo queda consistente.
Expected Files
frontend/index.htmlfrontend/assets/js/main.jsfrontend/assets/css/styles.cssbackend/app/writer_lock.pybackend/README.md