jdx/mise · error

retry loop should always return

Error message

retry loop should always return

What it means

retry_async loops a fixed number of attempts and is written so the loop always terminates via return/continue paths, leaving last_err populated on exhaustion. The final Err(last_err.expect(...)) panics only if the loop somehow exits with no recorded error — an internal invariant, not a user-triggerable condition.

Source

Thrown at crates/vfox/src/http.rs:173

            Ok(value) => return Ok(value),
            Err(err) => {
                if !is_transient(&err) || attempt + 1 >= attempts {
                    return Err(err);
                }
                let delay = retry_delay(attempt);
                log::warn!(
                    "HTTP {} attempt {} failed (transient): {}; retrying in {:?}",
                    url,
                    attempt + 1,
                    err,
                    delay
                );
                last_err = Some(err);
                tokio::time::sleep(delay).await;
            }
        }
    }
    Err(last_err.expect("retry loop should always return"))
}

View on GitHub (pinned to afd2eddd3a)

Solutions

1. Report as a mise bug (github.com/jdx/mise/issues) with the original wrapped network error and version
2. Retry the download — the underlying failure is whatever last_err was (typically network/HTTP)
3. Check connectivity/proxy settings if downloads were failing before the panic

// unreachable in practice; treat any occurrence as a bug report
if msg.contains('retry loop should always return') { report_bug_with_env(); }

When it happens

Trigger: Only via a logic bug in retry_async's control flow (e.g. future retry-handling changes) where all attempts are consumed without assigning last_err.

Common situations: Effectively never seen by users; appears only in modified/patched builds or as a crash report from a mise bug.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• cloned request builder should remain cloneable
• attestation requests must not have a streaming body
• Failed to create reqwest client
• BootstrapPart values have clap names
• bootstrap command is registered

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/c9ce64d98ff58c67. Report an issue: GitHub.