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
- Wait for the relay to report ready / retry the operation — the relay may still be connecting at startup.
- Restart the mise relay/session process and check its logs for upstream connection or auth errors.
- Verify nothing (proxy env vars, firewall) is intercepting the localhost `_session` health request.
- 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
- Wait for the relay's ready signal before issuing session commands
- Monitor relay process health and restart on crash
- Keep proxy/no_proxy settings from interfering with localhost requests
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
- expected a GitHub repository in OWNER/REPO form
- GitHub relay permits read-only repository operations only
- GitHub relay socket forwarding failed
- invalid relay path
- invalid relay path encoding
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)