jdx/mise · error

GitHub relay is not connected

Error message

GitHub relay is not connected

What it means

In `wait_command`, before handing the HTTP client to the session, the relay performs a health check against `http://localhost/_session` and requires a 204. If the health probe fails or returns any other status, the relay considers itself disconnected and bails with "GitHub relay is not connected". It means the local relay server isn't up, isn't ready, or its connection to GitHub is broken.

Solutions

  1. Wait for the relay to report ready / retry the operation — the relay may still be connecting at startup.
  2. Restart the mise relay/session process and check its logs for upstream connection or auth errors.
  3. Verify nothing (proxy env vars, firewall) is intercepting the localhost `_session` health request.
  4. If the relay persistently reports disconnected, check GitHub reachability/credentials and re-authenticate.
Defensive patterns

Strategy: retry

Validate before calling

// poll until the relay is ready before use
for _ in 0..30 {
    if reqwest::get("http://localhost/_session").await.map(|r| r.status() == 204) == Ok(true) { break; }
    tokio::time::sleep(std::time::Duration::from_millis(200)).await;
}

Try / catch

match session(client).await {
    Err(e) if e.to_string().contains("not connected") => {
        wait_for_relay_ready().await?;
        session(client).await
    }
    other => other,
}

Prevention

When it happens

Trigger: Calling the relay session while the relay process is not yet started or has exited; the `_session` endpoint returns a non-204 status (relay lost upstream connectivity); connection to the local relay port is refused.

Common situations: Running git/HTTP operations before the relay background task finished starting; relay crashed due to network/auth problems; firewall or proxy blocking localhost socket; stale environment pointing at a dead relay.

Understand the failure class

Background: ECONNREFUSED and "connection refused" / "could not connect to server" errors: what they mean and how to fix them — this error's family across 44 libraries.

Related errors


AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/192d0128f8c7ed4f. Report an issue: GitHub.

Appendix: source

Thrown at src/github_relay.rs:910

        command: &mut tokio::process::Command,
        socket: Option<&Path>,
    ) -> Result<std::process::ExitStatus> {
        let mut terminate =
            tokio::signal::unix::signal(tokio::signal::unix::SignalKind::terminate())?;
        let mut hangup = tokio::signal::unix::signal(tokio::signal::unix::SignalKind::hangup())?;
        let heartbeat = if let Some(socket) = socket {
            let client = Client::builder()
                .unix_socket(socket)
                .no_proxy()
                .timeout(Duration::from_secs(3))
                .build()?;
            if !client
                .get("http://localhost/_session")
                .send()
                .await
                .is_ok_and(|r| r.status() == 204)
            {
                bail!("GitHub relay is not connected");
            }
            Some(client)
        } else {
            None
        };
        let disconnected = async {
            let Some(client) = heartbeat else {
                std::future::pending::<()>().await;
                return;
            };
            let mut failures = 0;
            loop {
                tokio::time::sleep(Duration::from_secs(2)).await;
                if client
                    .get("http://localhost/_session")
                    .send()
                    .await
                    .is_ok_and(|r| r.status() == 204)

View on GitHub (pinned to 533346cc37)