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

Offen
  • Stimmt etwas nicht?
#7,705 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
18/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
backend

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Python
Sterne
29k
Forks
1.8k
Ø Merge
2 T. 22 Std.
Gemergte PRs (30 T.)
143

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus reflex-dev/reflex

Alle Issues in reflex-dev/reflex

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.