vitejs/vite · error · Error

Can not commit a Deps Optimization run as it was cancelled

Error message

Can not commit a Deps Optimization run as it was cancelled

What it means

A deps-optimization run produces a result object with `commit()` and `cancel()`; `cancel()` sets `cleaned` and deletes the processing dir. If `commit()` is then invoked, it detects `cleaned === true` and refuses to publish a half-deleted cache, throwing at optimizer/index.ts:581. This protects cache integrity: a cancelled run must never be promoted to the live cache.

Source

Thrown at packages/vite/src/node/optimizer/index.ts:581

      cleaned = true
      // No need to wait, we can clean up in the background because temp folders
      // are unique per run
      debug?.(colors.green(`removing cache dir ${processingCacheDir}`))
      try {
        // When exiting the process, `fsp.rm` may not take effect, so we use `fs.rmSync`
        fs.rmSync(processingCacheDir, { recursive: true, force: true })
      } catch {
        // Ignore errors
      }
    }
  }

  const successfulResult: DepOptimizationResult = {
    metadata,
    cancel: cleanUp,
    commit: async () => {
      if (cleaned) {
        throw new Error(
          'Can not commit a Deps Optimization run as it was cancelled',
        )
      }
      // Ignore clean up requests after this point so the temp folder isn't deleted before
      // we finish committing the new deps cache files to the deps folder
      committed = true

      // Write metadata file, then commit the processing folder to the global deps cache
      // Rewire the file paths from the temporary processing dir to the final deps cache dir
      const dataPath = path.join(processingCacheDir, METADATA_FILENAME)
      debug?.(
        colors.green(`creating ${METADATA_FILENAME} in ${processingCacheDir}`),
      )
      fs.writeFileSync(
        dataPath,
        stringifyDepsOptimizerMetadata(metadata, depsCacheDir),
      )

View on GitHub (pinned to 89620f09af)

Solutions

1. If you call the optimizer API programmatically, check the result's lifecycle — never call `commit()` after `cancel()`; track which one won the race.
2. Restart the dev server cleanly to reset optimizer state, and clear `node_modules/.vite` if the cache is suspect.
3. Reduce rapid config edits that invalidate the run; debounce file saves.
4. Update Vite — lifecycle races around cancel/commit have been fixed across versions.

Example fix

// before
const result = await runOptimize()
result.cancel()
await result.commit() // throws

// after
const result = await runOptimize()
if (!result.cancelled) await result.commit()

// If you drive the optimizer API, guard commit after cancel:
const result = await runOptimizeDeps(environment)
try { await result.commit() }
catch (e) {
  if (e instanceof Error && /cancelled/.test(e.message)) { /* expected after cancel; ignore */ return }
  throw e
}

When it happens

Trigger: Internally: the optimizer's processing run is cancelled (e.g. server close, new discovery invalidating the run, or explicit `cancel()`) and a code path still calls `commit()` on that same result object. Users rarely trigger this directly.

Common situations: Rapid config/source churn that invalidates the in-flight optimization; closing the dev server while optimization is mid-flight; race between a re-optimize and a browser request triggering commit; plugins or custom environment code calling the internal optimizer API out of order.

Related errors

• The build was canceled
• Module "${url}" was mistakenly invalidated during fetch phas
• Vite Internal Error: registerMissingImport is not supported
• ${this.name} environment.pluginContainer called before initi
• The following dependencies are imported but could not be res

AI-assisted analysis of vitejs/vite@89620f09af (2026-08-03). Data as JSON: /data/errors/e66969004bd71fb9.json. Report an issue: GitHub.