Cache replay restores outputs with their archived modification times, so mtime-based tools skip changed files
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ó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 72/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- rust, typescript, vite
- Lĩnh vực
- build-system, tooling
Hướng nghiên cứu
Start with crates/vt/src/session/cache/archive.rs, especially the metadata recording and unpacking lines linked in the issue; check how the tar crate handles modification times during extraction. The issue suggests disabling mtime preservation before unpacking. Confirm the behavior with the provided vp run gen reproduction and check that replayed outputs get fresh modification times while cache fingerprints remain content based.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Written by an AI agent (Claude) on behalf of @jasonkuhrt.
A cache hit restores each output file with the modification time it had when it was archived, not the time it was restored. A tool downstream that decides staleness by modification time then treats a replayed file with new content as older than its own last build, and skips it.
We hit this as a green type check on stale code. A generate task's outputs were replayed from an entry archived earlier, under an incremental TypeScript build whose build info stayed in place. The build reads an input only when it is newer than its build info, so it skipped the projects whose generated sources had just changed.
Repro with vite-plus 1.4.0:
// vite.config.ts
export default {
run: {
tasks: {
gen: {
command: 'cp in.txt out.txt',
cache: { input: ['in.txt'], output: ['out.txt'] },
},
},
},
};
echo a > in.txt
vp run gen # cache miss, executing
stat -f %m out.txt # 1792806461
rm out.txt
sleep 3
vp run gen # cache hit, replaying
stat -f %m out.txt # 1792806461, while `date +%s` is 1792806475
The archive records each file's metadata, its time included (header.set_metadata, archive.rs:39). The restore unpacks with tar's defaults (archive.rs:62-64), and tar 0.4.45 defaults preserve_mtime to true (src/archive.rs:62). Nothing in the cache code or docs says the times are meant to survive a restore.
The harm comes when the entry was archived before the downstream tool last ran. Within one checkout that's rare, because the local entry for a task is the latest one. Across machines and branches it's routine: the remote tier, or a cache directory carried between CI runs, replays content another run archived hours earlier, onto a checkout whose downstream build ran since.
A possible fix is archive.set_preserve_mtime(false) before unpack, so a restored file is dated when it lands. Vite Task's own fingerprints hash content (crates/vt/src/session/execute/fingerprint.rs), so its cache shouldn't be affected. A tool that compares two outputs of the same archive by time would see them restored at nearly the same moment, which seems the safer error.
Our workaround: before an incremental build, re-date each input whose status-change time is after its build info but whose modification time is before it. That's the signature of an extraction that kept an old time.
- Ngôn ngữ chính
- Rust
- Star
- 480
- Fork
- 50
- Merge trung bình
- 1 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 70
Chuẩn bị môi trường
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.
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của voidzero-dev/vite-task
-
A task output archive larger than the remote cache server's request limit can never be storedĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
voidzero-dev/vite-task#888 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
voidzero-dev/vite-task#886 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
voidzero-dev/vite-task#884 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
voidzero-dev/vite-task#879 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
vp run hangs after a failure when a cancelled task's detached descendant holds its IPC connectionĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
voidzero-dev/vite-task#878 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của voidzero-dev/vite-task
Issue tương tự
-
muse P3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
HerringtonDarkholme/hd-lang#923 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
longbridge/gpui-kit#3712 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation enhancement SIEM
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
ADORSYS-GIS/wazuh-agent-status#265 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
documentation enhancement SIEM
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
[Feature] 数据表查询结果转置后显示字段注释Đang mởai-priority/P2 enhancement user-priority/P0
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
t8y2/dbx#13641 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày