jdx/mise · error
{e}
Error message
{e} What it means
resolve_with_progress in src/toolset/mod.rs propagates errors from the tool-version list resolution (tvl.resolve) while reporting completion to the progress reporter. Channel-required resolution errors are re-raised directly; lockfile misses are downgraded to warnings when opts.warn_not_in_lockfile is set. The `{e}` message is whatever the underlying resolution failed with.
Solutions
- Read the underlying message and check network connectivity or the backend's availability.
- Pin an explicit, still-existing version instead of `latest` or a channel that can't be resolved.
- Update or regenerate mise.lock so entries match what upstream can resolve.
- Retry after transient network failures or configure a token if the backend rate-limited the request.
Example fix
# before node = "22" # resolves via network; fails offline # after node = "22.11.0" # pinned; resolvable from local cache/lockfile
Defensive patterns
Strategy: retry
Validate before calling
# pre-check that the requested version exists upstream before resolve mise ls-remote node@22.11.0 || echo "version not resolvable"
Try / catch
match resolve_with_opts(config, tvl, opts).await {
Err(e) if e.to_string().contains("network") || e.to_string().contains("timeout") => retry_with_backoff(3),
Err(e) => return Err(e),
Ok(ts) => Ok(ts),
} Prevention
- Pin explicit concrete versions instead of `latest` in CI.
- Keep mise.lock committed so resolution can succeed from lockfile data.
- Configure API tokens for version-listing backends to avoid rate limits.
- Cache tool version lists in offline/air-gapped environments.
When it happens
Trigger: Resolving tool versions (mise install/use) when the backend fails to list/resolve a requested version — network errors hitting the version provider, an unresolvable version request, or lockfile inconsistencies.
Common situations: Offline/CI environments where version listing HTTP calls fail, requesting `latest` when the registry is unreachable, or a version present in mise.lock but not resolvable upstream after upstream deleted a release.
Understand the failure class
Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.
Related errors
- previous lockfiles were preserved
- No current versions found after resolving toolset
- swift does not publish
- additional_artifacts must be an array in lockfile
- aube lockfile mapping keys must be strings
AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17).
Data as JSON: /api/errors/fb115dafea176847.
Report an issue: GitHub.
Appendix: source
Thrown at src/toolset/mod.rs:173
let versions = self
.versions
.clone()
.into_iter()
.map(|(ba, tvl)| {
let reporter = progress.as_ref().and_then(|p| p.start_tool(&ba.short));
(config.clone(), ba, tvl, opts.clone(), reporter)
})
.collect::<Vec<_>>();
let tvls = parallel::parallel(
versions,
|(config, ba, mut tvl, opts, reporter)| async move {
let result = crate::ui::resolve_progress::scope(
reporter.as_ref().map(|p| p.reporter()),
tvl.resolve(&config, &opts),
)
.await;
if let Some(reporter) = reporter {
reporter.complete(result.as_ref().err().map(|e| e.to_string()).as_deref());
}
if let Err(err) = result {
if Error::is_required_channel_resolution_err(&err) {
return Err(err);
}
if Error::is_not_in_lockfile(&err) && !opts.warn_not_in_lockfile {
debug!("Failed to resolve tool version list for {ba}: {err}");
} else {
// warn_once: a command may resolve the same toolset more than
// once, and repeating an identical failure adds no information.
warn_once!("Failed to resolve tool version list for {ba}: {err}");
}
}
Ok((ba, tvl))
},
)
.await?;
self.versions = tvls.into_iter().collect();View on GitHub (pinned to 533346cc37)