Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#904 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
rust
Domaine
build-system

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Rust
Étoiles
480
Forks
50
Merge moyen
1 j 5 h
PR mergées (30 j)
63

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de voidzero-dev/vite-task

Toutes les issues de voidzero-dev/vite-task

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.