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

Aperta
  • Qualcosa non va?
#7,705 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
18/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
29k
Fork
1.8k
Merge medio
2g 22h
PR unite (30g)
143

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di reflex-dev/reflex

Tutte le issue di reflex-dev/reflex

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.