jdx/mise · error

GitHub relay is not connected

Error message

GitHub relay is not connected

What it means

wait_command probes the relay's session endpoint (GET http://localhost/_session) and expects a 204 indicating the relay subprocess has finished connecting to GitHub. If the probe fails (connection refused, timeout, or a non-204 status) it reports "GitHub relay is not connected" — the session cannot proceed without a healthy relay.

Source

Thrown at src/github_relay.rs:900

        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 afd2eddd3a)

Solutions

1. Retry the session — transient startup slowness is the most common cause.
2. Check that the relay child process is running and inspect its stderr/logs for startup errors.
3. Verify nothing else occupies the relay's localhost port and that a firewall isn't blocking loopback.
4. Check GitHub connectivity/credentials from the host — the relay only answers 204 once its upstream connection is established.

let ready = reqwest::get("http://localhost/_session")
    .await.ok().map(|r| r.status() == 204).unwrap_or(false);
if !ready { /* wait and re-poll before proceeding */ }

match result {
    Err(e) if e.to_string().contains("GitHub relay is not connected") =>
        wait_then_retry(startup_deadline),
    other => other,
}

When it happens

Trigger: Polling for relay readiness during session startup when the relay process failed to start, crashed, is still initializing past the wait window, or answered with an unexpected status.

Common situations: Relay binary missing/failing to spawn; localhost port conflicts; slow networks keeping the relay from completing its GitHub connection within the wait budget; firewall software blocking loopback connections.

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

• Got HTML instead of text from {}
• cannot encode #{value.class} as JSON
• cannot encode #{value.class} as JSON
• Failed to read schema at {}: {}
• Failed to parse schema JSON: {}

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