Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Cache replay restores outputs with their archived modification times, so mtime-based tools skip changed files

未關閉
  • 哪裡不對？
#881 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
3/5
預估耗時
1-2 天
新手友好度
72/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
rust, typescript, vite
領域
build-system, tooling

研究方向

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.

由索引模型根據 Issue 內容生成。

描述

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.

主要語言
Rust
星號
480
分支
50
平均合併
1 天 4 小時
30 天內合併 PR
61

環境準備

在 Codespaces 中開啟

在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

voidzero-dev/vite-task 的其他 Issue

查看 voidzero-dev/vite-task 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。