Cómo recuperar un día perdido sin publicar fuera de orden

Primero determina qué día falta realmente. Descarga vivo y lee feedDate. Compárala con la fecha local actual. Si el vivo muestra hace dos días, el objetivo inmediato no es publicar staging antiguo por reflejo, sino decidir qué edición corresponde al día que el lector necesita ahora. El sistema debe basarse en calendario real y no en el último artefacto disponible, porque disponibilidad y vigencia son cosas distintas.

No cambies la etiqueta de un run viejo. Una edición investigada para el 29 no se convierte en edición del 30 reemplazando feedDate e IDs. Sus noticias, fuentes y contexto pertenecen a otro snapshot. Reetiquetar destruye trazabilidad y puede presentar hechos viejos como si fueran nuevos. Si un día se perdió, genera el run correcto o reutiliza solo un staging que ya fue construido específicamente para esa fecha.

Conserva un solo runKey por fecha. Usa <feedDate>-0001 tanto para intentos iniciales como para recuperación. Crear 0002 por cada retry dificulta dedupe y puede producir dos ediciones competidoras. El estado de recuperación vive en las verificaciones del mismo run: staging válido, vivo válido, backup y correo. El runKey identifica la edición; los intentos no necesitan cambiar su identidad.

Promueve antes de regenerar cuando existe staging correcto. Si staging ya contiene el run actual y pasa todas las validaciones, reutilízalo. El problema es de entrega, no de contenido. Descargarlo de nuevo y promoverlo reduce tiempo y evita diferencias. Solo si ni staging ni vivo contienen una edición válida del día se inicia investigación y generación completa.

Después del vivo cierra sus efectos secundarios. Una vez verificada la publicación, crea backup y correo del mismo runKey. No avances a mañana dejando estos pasos pendientes si son parte del criterio de éxito. El orden facilita auditoría y permite que la próxima ejecución sepa que hoy está cerrado. Si el correo falla, no debe revertir el vivo; la recuperación completa únicamente esa notificación.

Luego prepara el día siguiente. Con el día actual sano, calcula mañana y construye staging. Así se recupera la cadencia normal en la misma sesión si existe tiempo. El sistema no necesita esperar a la próxima hora programada para ponerse al día. Esta regla es especialmente útil después de una pausa del scheduler: una ejecución puede cerrar el hueco visible y devolver margen para el próximo cambio de día.

Registra qué fechas quedaron saltadas. Si hubo más de un día sin publicación, el histórico puede conservar la ausencia en lugar de inventar ediciones retroactivas que nunca estuvieron vivas. La prioridad operativa es restablecer el presente. Crear contenido retrospectivo solo tiene sentido si existe una necesidad editorial explícita. De lo contrario, es mejor un historial honesto que una continuidad fabricada después.

La recuperación termina cuando el orden vuelve a ser obvio. Vivo debe ser hoy; staging debe ser mañana; backup y correo deben corresponder a vivo. Cuando esas cuatro relaciones se cumplen, NewsDesk recuperó su ritmo. Esta definición evita estados ambiguos y permite que la próxima corrida diaria vuelva a una lógica sencilla. La continuidad se restaura cerrando fronteras, no acumulando más excepciones.

Valida la frescura de las fuentes durante la recuperación. Cuando el día actual debe generarse varias horas después de la ventana normal, vuelve a buscar acontecimientos recientes en lugar de reutilizar automáticamente candidatos antiguos. La fecha del feed representa hoy, pero publishedAt conserva la fecha real de cada fuente. Ese equilibrio permite recuperar continuidad sin falsificar el tiempo de los hechos y sin llenar el hueco con una edición que ya estaba superada.