46 lines
1.8 KiB
Markdown
46 lines
1.8 KiB
Markdown
# TASK-104-landing-loading-state-and-stale-lock-hardening
|
|
|
|
## Goal
|
|
Corregir dos problemas de producto/operación ya detectados:
|
|
1. la landing muestra primero datos fake estáticos antes de hidratar
|
|
2. 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
|
|
1. 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
|
|
2. 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
|
|
3. 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.html`
|
|
- `frontend/assets/js/main.js`
|
|
- `frontend/assets/css/styles.css`
|
|
- `backend/app/writer_lock.py`
|
|
- `backend/README.md`
|