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 天 3 小时
30 天内合并 PR
62

环境准备

在 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 摘要。