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

Aberta
  • Algo errado?
#7,705 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
18/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
29k
Forks
1.8k
Merge médio
2d 22h
PRs com merge (30d)
143

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de reflex-dev/reflex

Todas as issues de reflex-dev/reflex

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.