Retención, caché y disponibilidad

Un registro de proxy que guarda lo que ya sirvió convierte la caída de un registro público en un problema menor: lo que está en la caché sigue entregándose. Las construcciones que dependen solo de lo ya descargado terminan bien; las que necesitan algo que nunca se pidió fallan, porque no hay de dónde sacarlo.

Eso significa que la disponibilidad depende de qué hay guardado, y por tanto de qué política decide cuándo se borra algo. Una purga agresiva puede convertir un incidente ajeno en un día perdido propio.

El registro de la caída cuenta qué construcción falló y por qué. La razón es siempre la misma: algo que el proyecto pedía no estaba en la caché. Es una información útil por sí sola: dice qué dependencias se pidieron por primera vez durante la caída, que suelen ser las más recientes y las menos probadas.

Abre el registro de la caída del público.

La caché no se entera de que el origen retiró un paquete. Si el registro público elimina un paquete por contener código malicioso, la copia que el proxy guardó sigue entregándose a quien la pida, y es la que estaba en los archivos de bloqueo de los proyectos que ya la usaban.

El aviso del público llega por otro canal (una alerta, una lista de avisos), no a través del proxy. El inventario de la caché sí puede llevar el estado del paquete aguas arriba, y ese es el dato que cruza las dos fuentes.

Mira el inventario de la caché y el aviso recibido.

Una política de retención razonable tiene dos reglas. Se puede purgar lo que lleva más de cierto tiempo sin usarse. Pero nunca se purga lo que un archivo de bloqueo exige, porque eso rompería una construcción reproducible: el proyecto pide exactamente esa versión y, si ya no está, la reconstrucción falla o, peor, la sustituye otra.

Para ver cuánto espacio se libera, se suma el tamaño de lo que cumple las dos condiciones: más de treinta días sin uso a fecha de hoy y fuera de los archivos de bloqueo. Usa la fecha que da la política.

El paquete retirado por malicioso está en la caché y en el archivo de bloqueo de varios proyectos. La regla «nunca purgar lo que un bloqueo exige» no puede ganarle a esto: aquí lo que hay que hacer es lo contrario. Se bloquea la entrega de esa versión en el registro, se purga la copia, y se investiga con el registro de acceso (la sala siguiente) quién la descargó y dónde corrió.

Dejarla porque «un proyecto la necesita» es dejar que un archivo de bloqueo apunte a algo que la empresa ya sabe que no es de fiar.