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

Đang mở
  • Có gì không ổn?
#7,705 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
18/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
29k
Fork
1.8k
Merge trung bình
2 ngày 22 giờ
Pull request đã merge (30 ngày)
143

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của reflex-dev/reflex

Tất cả issue của reflex-dev/reflex

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.