assets: hardlink/copy fallbacks for shared assets are not cleaned up when the source vanishes

Abierto
  • ¿Algo no está bien?
#7,705 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
18/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

The stale-cleanup logic is remove_stale_external_asset_symlinks, and the fallback artifacts are produced in the rx.asset(shared=True) path where asset() raises FileNotFoundError. Read how the external assets directory mirrors the module path, then decide how a hardlink or copy could be recognised as stale. The issue explicitly asks a maintainer to choose between three designs, so it is not ready for a first-time fix; done means a recorded decision, not a patch.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Follow-up from #7703 (Windows fallback for rx.asset(shared=True)).

remove_stale_external_asset_symlinks can identify stale shared assets for free because a symlink whose target is gone is detectable from the destination alone. The new fallbacks lose that property:

  • A hardlink whose partner file was deleted still holds the content (the inode survives), and nothing on the destination reveals that the source module is gone.
  • A copy is a plain regular file; whether its source still exists is unknowable without provenance.

Consequence: if a library that exposed shared assets is uninstalled (or an asset file is deleted/renamed), the fallback artifact remains in assets/external and keeps being served/symlinked into fresh builds, where the symlink path would have been pruned. Note the compile itself still fails loudly while the module exists but the asset file is missing (FileNotFoundError in asset()), so the gap only shows for uninstalled modules.

Options, roughly in increasing cost:

  1. Leave as-is: stale files are cruft, not corruption.
  2. Provenance sidecar (e.g. a parallel non-served metadata tree) — doubles the tree and needs its own sync/cleanup.
  3. Derive the source location from the destination path (external dir mirrors module_path/asset), import the module to locate the caller file, and check existence — avoids metadata but imports arbitrary modules during cleanup.

Marking this up for a maintainer call rather than picking one inside the fallback PR.

Lenguaje dominante
Python
Estrellas
29k
Forks
1.8k
Merge medio
2 d 22 h
PR fusionados (30 d)
143

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de reflex-dev/reflex

Todos los issues de reflex-dev/reflex

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.