Cached compound command can replay a later step after preceding vp exec rewrites its input

Bắt đầu bằng cách clone repro được liên kết, xem xét vite.config.ts, scripts/generate.mjs và scripts/normalize.mjs, rồi chạy cả hai trường hợp tái hiện bằng PowerShell. Truy vết cách xử lý cache của lệnh ghép từ điểm vào vp exec; hoàn tất khi một bước && về sau không tìm thấy cache sau khi một bước trước đó ghi lại đầu vào của nó, với cả hai kiểm tra cuối cùng đều đạt.

Summary

A cached compound command can replay a later && step even after an earlier vp exec ... step rewrites the file that the later step reads.

This is not specific to vp fmt: the same behavior reproduces when the later step is a plain node command that reads and rewrites the generated file.

Repro repo: https://github.com/SegaraRai/vitetask-repro04

Environment

Observed with:

• vite-plus: 0.1.19
• package manager: pnpm@10.33.2
• Node: 24.x
• OS: Windows

The repro commands below use PowerShell syntax for setting environment variables.

Reproduction

Clone and install:

git clone https://github.com/SegaraRai/vitetask-repro04.git
cd vitetask-repro04
vp install

The repo defines these tasks in vite.config.ts:

tasks: {
  generate: {
    command: "vp exec node ./scripts/generate.mjs && vp fmt src/generated",
    cache: true,
    input: ["scripts/generate.mjs"],
  },
  "generate:normalize": {
    command: "vp exec node ./scripts/generate.mjs && node ./scripts/normalize.mjs",
    cache: true,
    input: ["scripts/generate.mjs", "scripts/normalize.mjs"],
  },
}

Case 1, with vp fmt as the second step:

vp cache clean
$env:REPRO_MESSAGE = "first"; vp run generate
$env:REPRO_MESSAGE = "second"; vp run generate
vp fmt src/generated --check

Case 2, with plain node as the second step:

vp cache clean
$env:REPRO_MESSAGE = "first"; vp run generate:normalize
$env:REPRO_MESSAGE = "second"; vp run generate:normalize
node ./scripts/check-normalized.mjs

There is also a convenience script if useful:

vp exec node ./scripts/repro.mjs

Observed behavior

On the second run, the first step executes uncached, rewrites src/generated/messages.ts, and the second step is replayed from cache.

Representative output for case 1:

$ vp exec node ./scripts/generate.mjs ⊘ cache disabled
$ vp fmt src/generated ◉ cache hit, replaying

Representative output for case 2:

$ vp exec node ./scripts/generate.mjs ⊘ cache disabled
$ node ./scripts/normalize.mjs ◉ cache hit, replaying

The final check then fails because the generated file contains fresh content from the first step but did not receive the second step's normalization/formatting.

Expected behavior

The second step should not be replayed when its previously tracked input file was modified by an earlier step in the same compound command. It should miss cache and run against the current file contents.

Notes

• This does not appear to be specific to vp fmt; the plain node ./scripts/normalize.mjs variant reproduces the same behavior.
• In local testing, replacing the first command with plain node ./scripts/generate.mjs did not reproduce the issue.
• Including the changing value in the task's tracked env/input avoids this particular repro, but the concern here is intra-task filesystem changes between && items.
• This does not seem to be about restoring output files from cache. The file is rewritten by the preceding uncached step in the current run; the problem is that the following step is still replayed even though its read input has just changed.

A possible direction is that cache validation for later && items may need to account for filesystem writes from earlier items in the same task, especially when the earlier item is an expanded/cache-disabled vp exec invocation.