voidzero-dev / voidzero-dev/vite-task
Windows fspy reports the workspace root as a read-write overlap and prevents caching
Personne n'a encore pris cette issue.
- Langage dominant
- Rust
- Étoiles
- 466
- Forks
- 42
- Merge moyen
- 1 j 15 h
- PR mergées (30 j)
- 19
Description
Summary
A cached task using the default automatic input and output inference completes successfully on Windows, but Vite Task refuses to store the cache entry because fspy reports the workspace root as both read and written.
The same fixture completes without this cache diagnostic on Linux and macOS.
Reproduction
This was captured by a real cross-platform Vite+ snapshot test added while working on voidzero-dev/vite-plus#2151.
- Failed Windows CI job: https://github.com/voidzero-dev/vite-plus/actions/runs/29151101121/job/86540717812
- Vite+ diagnostic commit: https://github.com/voidzero-dev/vite-plus/commit/919ed21669917a0e6e9d9a51167e7fb621f99bb9
- Vite Task revision used by that Vite+ build:
cb580c214bb2314fc1f633a3812782c9b3a1d956 - Failing test:
vite_task_bunx_wrapper::vite_task_bunx_wrapper
The fixture used a real managed Bun 1.3.14 installation rather than a mocked executable. Its configured task was equivalent to:
export default {
run: {
tasks: {
'gate:test': {
command: 'bun probe',
},
},
},
}
The package script executed a real package binary through Bun:
{
"scripts": {
"probe": "bunx --bun probe"
},
"dependencies": {
"probe-bin": "file:./probe-bin"
},
"devEngines": {
"packageManager": {
"name": "bun",
"version": "1.3.14",
"onFail": "download"
}
}
}
The snapshot steps were:
vp install
vp run gate:test
vp run --last-details
The command itself succeeded:
$ bun probe
$ bunx --bun probe
probe binary ran
Only the Windows run then reported:
vp run: vite-task-bunx-wrapper#gate:test not cached because it modified its input.
[1] vite-task-bunx-wrapper#gate:test: $ bun probe ✓
→ Not cached: read and wrote ''
The empty relative path is the workspace root. Re-running the task cannot hit the cache because no entry was stored.
Expected behavior
The task should be cacheable when the process tree does not actually modify an inferred input. In this fixture, a subsequent identical run should be able to hit the cache.
Actual behavior
On Windows, fspy reports the workspace root as both read and written. Vite Task treats the empty workspace-relative path as an input/output overlap and skips the cache update.
Analysis
TrackedPathAccesses::from_raw strips the workspace root from absolute paths. An access to the root itself therefore becomes an empty RelativePathBuf, which is retained in both path_reads and path_writes:
observe_fspy then performs an exact intersection between the inferred read and write path sets. The empty path is returned as read_write_overlap, causing CacheNotUpdatedReason::InputModified:
One possible source of the false positive is the Windows access-mode mapping. The Windows preload records the requested access mask when intercepting NtCreateFile/NtOpenFile, before forwarding the real call. Directory access rights share bit values with FILE_WRITE_DATA and FILE_APPEND_DATA, so opening a directory with the capability to add children may be classified as a write even when the process does not mutate it.
The existing diagnostic only contains the aggregated path. It does not identify the originating PID/process, access mask, create disposition/options, or whether the intercepted call succeeded, so the exact syscall in the Bun process tree is not yet known.
A regression test should preserve real root-directory input tracking while ensuring that a directory-handle access which does not mutate the workspace does not make an otherwise cacheable Windows task permanently uncacheable.
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez dans crates/vite_task/src/session/execute/tracked_accesses.rs et cache_update.rs, en suivant TrackedPathAccesses::from_raw et en observant observe_fspy pour comprendre comment le chemin vide relatif au workspace devient un chevauchement. Reproduisez le cas Windows vite_task_bunx_wrapper::vite_task_bunx_wrapper et examinez le suivi des accès Windows autour de l’arbre réel des processus Bun. Le travail est terminé lorsqu’un test de régression préserve le suivi des entrées du répertoire racine, tandis qu’un accès qui ne modifie pas le workspace n’empêche plus la mise en cache.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- bun, rust
- Domaine
- devtools, operating-systems, testing-qa
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 48/100