jdx/mise · error
unexpected provenance for
Error message
unexpected provenance for {tv} What it means
`validate_provenance_settings` cross-checks that the provenance actually recorded for a tool version matches what the current settings require. For tools like Ruby (which layer `settings.ruby.github_attestations` over the global `github_attestations`), if a provenance record exists but is not of the expected GitHub-attestations kind, it bails with `unexpected provenance for {tv}`.
Solutions
- Regenerate the lockfile with the current mise version and current settings so provenance is rewritten in the expected form
- Delete the stale lockfile (or affected tool entries) and re-lock
- Ensure `github_attestations` settings match how the lockfile was originally produced
- Avoid mixing lockfiles produced under different backend/settings configurations
Example fix
# before: stale lockfile with unexpected provenance # after: regenerate rm mise.lock && mise lock
Defensive patterns
Strategy: validation
Validate before calling
// before trusting the lockfile, check provenance kind matches settings
if lockfile_entry.provenance
.as_ref()
.map(|p| !p.is_github_attestations())
.unwrap_or(false)
{
// regenerate: stored provenance doesn't match github_attestations settings
} Prevention
- Regenerate lockfiles after upgrading mise or changing attestation settings
- Share identical settings.toml across the team so lockfiles are produced uniformly
- Don't hand-edit or migrate lockfiles between different backend configurations
- Delete stale lockfiles when provenance mismatch errors appear
When it happens
Trigger: Calling `is_current` or `generate` on a lockfile entry for a tool version whose stored provenance type doesn't match the backend's expected kind — e.g. a lockfile written by a different backend or older mise version recording non-GitHub provenance where GitHub attestations are expected/required.
Common situations: Upgrading mise across a provenance format change; hand-editing or migrating lockfiles; switching a tool between backends (e.g. from a generic backend to ruby core) so the recorded provenance no longer matches; stale lockfiles from a colleague using different settings.
Understand the failure class
Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.
Related errors
- {error}
- aube lockfile must contain a mapping
- invalid dependency graph digest
- invalid dependency sidecar path
- lockfile generation would downgrade additional artifact…
AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17).
Data as JSON: /api/errors/31c4efa36f6b699c.
Report an issue: GitHub.
Appendix: source
Thrown at src/lockfile/generate.rs:872
.ensure_provenance_setting_enabled(tv, platform),
BackendType::Core
if matches!(ba.full_without_opts().as_str(), "core:python" | "core:ruby") =>
{
crate::backend::ensure_provenance_setting_enabled(tv, platform, |provenance| {
let settings = Settings::get();
let enabled = if ba.full_without_opts() == "core:python" {
settings
.python
.github_attestations
.unwrap_or(settings.github_attestations)
} else {
settings
.ruby
.github_attestations
.unwrap_or(settings.github_attestations)
};
if !provenance.is_github_attestations() {
bail!("unexpected provenance for {tv}");
}
Ok(!enabled)
})
}
_ => Ok(()),
}
};
validate(&tv)?;
for artifact in &info.additional_artifacts {
tv.lock_platforms.get_mut(platform).unwrap().provenance = artifact.provenance.clone();
validate(&tv)?;
}
Ok(())
}
struct ProgressGuard<'a> {
report: &'a dyn crate::ui::progress_report::SingleReport,
finished: bool,View on GitHub (pinned to 533346cc37)