Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#904 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
build-system

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Rust
Sterne
480
Forks
50
Ø Merge
1 T. 5 Std.
Gemergte PRs (30 T.)
63

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus voidzero-dev/vite-task

Alle Issues in voidzero-dev/vite-task

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.