fspy misses Bun file reads on Linux (glibc), so cached tasks replay stale output
維護者通常 1 天內回覆
@wan9chi 已經在處理了。
開始於 2026年9月30日。
評估
這個 Issue 還沒有評估資料。
描述
Note: This issue was written by an AI agent (Claude) on behalf of @chenxin-yan. The reproduction below was run and checked; the suspected cause is marked as unconfirmed.
On Linux with glibc, automatic input tracking does not see files that Bun reads. A cached task that runs bun then replays stale output after one of those files changes. The same read done by node is tracked correctly.
This is the Linux counterpart of #532. #542 fixed it for macOS only.
Reproduction
package.json:
{ "name": "vt-bun-repro", "private": true, "type": "module", "devDependencies": { "vite-plus": "1.0.0" } }
vite.config.ts:
import { defineConfig } from "vite-plus";
export default defineConfig({
run: {
tasks: {
"read-node": `node -e "console.log(require('fs').readFileSync('data.txt', 'utf8'))"`,
"read-bun": `bun -e "console.log(require('fs').readFileSync('data.txt', 'utf8'))"`,
},
},
});
echo v1 > data.txt
npm install
npx vp run read-node && npx vp run read-bun # populate the cache
echo v2 > data.txt
npx vp run read-node
npx vp run read-bun
Output after the change:
$ node -e "..." ○ cache miss: 'data.txt' modified, executing
v2
$ bun -e "..." ◉ cache hit, replaying
v1
bun build behaves the same way: editing its entry file is not detected. We first saw this through crust build, which bundles with an embedded Bun. Edits to the CLI's TypeScript sources replayed a stale bundle, while reads done by Node were tracked. Listing the sources in cache.input works around it.
Environment
- vite-plus 1.0.0 (also 1.0.0-rc.1)
- Bun 1.4.2, and the Bun embedded in
@crustjs/crust0.5.0 - Node 26.10.0 and 24.21.0
- Linux 6.18 x86_64, glibc 2.42 (NixOS)
Suspected cause (unconfirmed)
According to crates/fspy/README.md, fspy on glibc Linux uses LD_PRELOAD for dynamically linked executables, and seccomp_unotify only for fully static binaries. Bun is dynamically linked against glibc (ldd lists libc.so.6), so only the preload path applies. Under strace, Bun's reads of the edited files appear as ordinary openat system calls. They seem to be issued directly rather than through the interposed libc functions. I have not confirmed this inside Bun's source.
Ask
Observe Bun's file accesses on Linux, for example through the seccomp path. Alternatively, fail closed or warn when a traced process's reads cannot be observed. Silently replaying stale output means a cached build or check can pass on changed inputs.
- 主要語言
- Rust
- 星號
- 478
- 分支
- 48
- 平均合併
- 1 天 4 小時
- 30 天內合併 PR
- 64
環境準備
在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
voidzero-dev/vite-task 的其他 Issue
-
vp run hangs after a failure when a cancelled task's detached descendant holds its IPC connection未關閉
難度 4/5 3-5 天 新手友好度 48/100
voidzero-dev/vite-task#878 ·
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 28/100
voidzero-dev/vite-task#876 ·
維護者通常 1 天內回覆
-
Existence probes of pnpm-workspace.yaml become content inputs, so any manifest edit misses every task可能已有人在做 @lifeiscontent 於 3 天前認領。 未關閉
難度 4/5 3-5 天 新手友好度 45/100
voidzero-dev/vite-task#860 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 68/100
voidzero-dev/vite-task#858 · 1 個 reaction ·
維護者通常 1 天內回覆
-
Concurrent cache hits for the same task fail to restore outputs with "File exists (os error 17)"可能已有人在做 @tlq5l 於 4 天前認領。 未關閉
難度 4/5 3-5 天 新手友好度 48/100
voidzero-dev/vite-task#846 · 2 則留言 ·
維護者通常 1 天內回覆
查看 voidzero-dev/vite-task 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
feature
難度 1/5 1 小時以內 新手友好度 92/100
dsx-ai-factory/infra-controller#8145 ·
維護者通常 1 天內回覆
-
bug: workspace access hint suggests a --subject command that fails for hyphen-leading OIDC subjects未關閉
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
type: bug
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
A-FFI C-Testing D-Straightforward S-Ready
難度 2/5 1-3 小時 新手友好度 75/100
維護者通常 1 天內回覆