astrid-runtime/astrid · error

host-local transport is not implemented on this platform

Error message

host-local transport is not implemented on this platform

What it means

Astrid's host-local transport has real backends only for Unix (Unix domain sockets) and Windows (named pipes). On any other target (or in the Unix test-only fallback path) every transport entry point returns io::ErrorKind::Unsupported with this message via unsupported_backend_error(). It signals that the requested host-local IPC operation cannot work on the current platform at all.

Solutions

1. Build and run on a supported platform (unix or windows); there is no software fallback for host-local IPC
2. If cross-compiling is intentional, gate the code path that uses the host-local transport behind cfg(unix)/cfg(windows) or a feature flag
3. If you see this on Linux/macOS/Windows, check that a platform module (unix.rs / windows.rs) is actually compiled in and no cfg attribute is excluding it

Example fix

// before
let conn = transport.connect(&path).await?; // unsupported target
// after
#[cfg(any(unix, windows))]
let conn = transport.connect(&path).await?;
#[cfg(not(any(unix, windows)))]
return Err(otherwise_suitable_transport());

#[cfg(any(unix, windows))]
const HOST_LOCAL_SUPPORTED: bool = true;
#[cfg(not(any(unix, windows))]
const HOST_LOCAL_SUPPORTED: bool = false;

match transport.connect(&path).await {
    Err(e) if e.kind() == std::io::ErrorKind::Unsupported => {
        // platform lacks host-local transport: use alternative IPC or abort
    },
    other => other?,
}

When it happens

Trigger: Calling connect, connect_outcome, bind, accept, probe, or endpoint_is_present on the host-local transport while compiled for a platform that is neither unix nor windows.

Common situations: Building/running Astrid on an embedded or exotic OS target without a host-local IPC backend; a #[cfg] misconfiguration that disables both backends during cross-compilation.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

• stable private directory identity is unavailable
• stable private file identity is unavailable
• Windows named-pipe endpoint disappeared while waiting
• Windows named-pipe endpoint is absent
• Windows named-pipe endpoint is occupied but unavailable

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/a11af82d5b39cffd. Report an issue: GitHub.

Appendix: source

Thrown at crates/astrid-core/src/local_transport.rs:28

//! types used before this seam was introduced. On Windows, the caller's path
//! is a portable API token combined with the current process token SID to form
//! a private, path-scoped pipe name. Backends own endpoint presence checks,
//! stale cleanup, connection probing, and same-user peer verification so
//! callers do not assume filesystem sockets and unrelated endpoints stay independent.

use std::io;
use std::path::Path;
#[cfg(not(any(unix, windows)))]
use std::pin::Pin;
#[cfg(not(any(unix, windows)))]
use std::task::{Context, Poll};

#[cfg(not(any(unix, windows)))]
use tokio::io::{AsyncRead, AsyncWrite, ReadBuf};

#[cfg(any(all(test, unix), not(any(unix, windows))))]
fn unsupported_backend_error() -> io::Error {
    io::Error::new(
        io::ErrorKind::Unsupported,
        "host-local transport is not implemented on this platform",
    )
}

/// A connected host-local byte stream.
#[cfg(unix)]
pub use tokio::net::UnixStream as LocalStream;

/// A connected Windows named-pipe stream.
#[cfg(windows)]
pub use windows_backend::LocalStream;

/// An unconstructable placeholder on hosts without a local transport backend.
#[cfg(not(any(unix, windows)))]
#[derive(Debug)]
pub struct LocalStream {
    _private: (),

View on GitHub (pinned to affd8760f4)