Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

cache.output: opt-in exact restore, so a hit removes files the cached run did not write

Aperta
  • Qualcosa non va?
#904 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
build-system

Direzione di ricerca

Read crates/vt/src/session/cache/archive.rs around lines 56–65 and crates/vt/src/session/cache/mod.rs around lines 589–600 to follow cache restoration; then inspect collect_glob_paths in crates/vt/src/session/execute/cache_update.rs. The issue proposes an opt-in replace flag for object-form output entries that removes matching files missing from the archive before unpacking. Done means replacement entries restore exact matching outputs while entries without the flag and { auto: true } keep current behavior; the payload names no tests.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Written by an AI agent (Claude) on behalf of @jasonkuhrt.

Problem

A cache hit unpacks the output archive over the workspace and deletes nothing (archive.rs L56-65, called from restore). For a task whose run replaces a folder, a hit therefore does not leave what a run leaves: a file in that folder that the cached run never wrote survives the hit.

Reproduction on vite-plus 1.4.0:

// vite.config.ts
import { defineConfig } from 'vite-plus';

export default defineConfig({
  run: {
    tasks: {
      generate: {
        command: 'node generate.mjs',
        cache: {
          input: ['generate.mjs', 'names.txt'],
          output: ['generated/**'],
        },
      },
    },
  },
});

// generate.mjs: replaces generated/ whole, one file per name in names.txt
import { mkdirSync, readFileSync, rmSync, writeFileSync } from 'node:fs';

rmSync('generated', { recursive: true, force: true });
mkdirSync('generated');
for (const name of readFileSync('names.txt', 'utf8').split(/\s+/).filter(Boolean)) {
  writeFileSync(`generated/${name}.ts`, `export const ${name} = 1;\n`);
}

$ echo 'a b' > names.txt
$ vp run generate
$ node generate.mjs
$ ls generated
a.ts  b.ts

$ echo 'export const c = 1;' > generated/c.ts    # a file an earlier run left
$ vp run generate
$ node generate.mjs ◉ cache hit, replaying
$ ls generated
a.ts  b.ts  c.ts                                  # c.ts survives the hit

$ vp run --no-cache generate
$ node generate.mjs ⊘ cache disabled
$ ls generated
a.ts  b.ts                                        # a run removes it

In practice c.ts comes from the checkout's own earlier run: a commit removes or renames something the task generates a file for, the checkout pulls it, and the remote cache already holds the run for the new commit. We hit this with a Prisma client generator: a removed scalar's file outlived the restore, and type checking failed with TS2307 on its now-missing import.

Why the runner can't infer it

The disk plus the archive can't tell a leftover from a file the task means to keep. If the command writes one file per name and deletes nothing, a run also leaves c.ts, and today's merge matches that run. Only the config author knows that a run replaces the folder.

Proposal

An opt-in on the object form of an output entry:

cache: {
  output: [{ pattern: 'generated/**', replace: true }],
},

On a hit, before unpacking, the restore matches the entry's pattern against the disk with the same collect_glob_paths that builds the archive, negative globs included, and deletes the matches the archive lacks. Entries without replace, and { auto: true }, keep today's behavior.

  • With #901 (leave outputs that already match untouched), a replace hit becomes an exact sync: matching files untouched, changed files rewritten, leftovers removed.
  • Docs: a replace entry owns every file its pattern matches. Two tasks whose replace patterns overlap would delete each other's files on a hit.
  • The name replace is a suggestion.

The workaround available today, an uncached task that deletes the outputs before the cached one runs, makes every output file disappear for as long as the restore takes, so another task of the same run or an editor reading them in that window sees them missing.

Lingua principale
Rust
Stelle
480
Fork
50
Merge medio
1g 5h
PR unite (30g)
63

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di voidzero-dev/vite-task

Tutte le issue di voidzero-dev/vite-task

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.