neondatabase/neon · error

real_ext_name {} is not found

Error message

real_ext_name {} is not found

What it means

Thrown by RemoteExtSpec::get_ext() in neon's compute_api when the extension name passed both the library_index mapping (if applicable) and the public/custom allow-list, but is absent from RemoteExtSpec.extension_data (the map holding control_data and archive_path used to build the remote download path). Reaching it means the RemoteExtSpec is internally inconsistent: an extension is advertised in the allow-list but has no download metadata.

Source

Thrown at libs/compute_api/src/spec.rs:425

        // If not, then it is not allowed to be used by this compute.
        if !self
            .public_extensions
            .as_ref()
            .is_some_and(|exts| exts.iter().any(|e| e == real_ext_name))
            && !self
                .custom_extensions
                .as_ref()
                .is_some_and(|exts| exts.iter().any(|e| e == real_ext_name))
        {
            return Err(anyhow::anyhow!("extension {} is not found", real_ext_name));
        }

        match self.extension_data.get(real_ext_name) {
            Some(_ext_data) => Ok((
                real_ext_name.to_string(),
                Self::build_remote_path(build_tag, pg_major_version, real_ext_name)?,
            )),
            None => Err(anyhow::anyhow!(
                "real_ext_name {} is not found",
                real_ext_name
            )),
        }
    }

    /// Get the architecture-specific portion of the remote extension path. We
    /// use the Go naming convention due to Kubernetes.
    fn get_arch() -> &'static str {
        match std::env::consts::ARCH {
            "x86_64" => "amd64",
            "aarch64" => "arm64",
            arch => arch,
        }
    }

    /// Build a [`RemotePath`] for an extension.
    fn build_remote_path(

View on GitHub (pinned to 8f60b04da4)

Solutions

1. Dump the RemoteExtSpec and verify the failing extension has an extension_data entry; if missing, the spec itself is broken — report it as a control-plane/extension-registry inconsistency
2. Update the component that produced the spec (control plane or extension registry) so allow-list and extension_data stay in sync
3. As a workaround, remove the extension from the compute request until its data entry exists
4. If you build RemoteExtSpec in tests, populate extension_data for every allow-listed name

Example fix

// before (test/spec construction)
spec.public_extensions = Some(vec!["pgcrypto".into()]);
// extension_data left empty -> error 104

// after
spec.public_extensions = Some(vec!["pgcrypto".into()]);
spec.extension_data.insert(
    "pgcrypto".into(),
    ExtensionData { control_data: Default::default(), archive_path: "ext/pgcrypto.tar.zst".into() },
);

// Detect the inconsistent state up front:
fn spec_is_consistent(spec: &RemoteExtSpec) -> Vec<String> {
    spec.public_extensions.iter().flatten()
        .chain(spec.custom_extensions.iter().flatten())
        .filter(|e| !spec.extension_data.contains_key(*e))
        .cloned()
        .collect()
}

// Treat as a spec-building bug, not a user error:
if let Err(e) = spec.get_ext(name, is_lib, tag, ver) {
    if e.to_string().contains("real_ext_name") {
        tracing::error!("RemoteExtSpec inconsistent: {e}");
    }
    return Err(e);
}

When it happens

Trigger: get_ext(name, ...) where name appears in public_extensions/custom_extensions but has no entry in extension_data. This requires malformed or version-skewed control-plane input: the allow-list and the data map are built from different extension sets.

Common situations: Control plane / compute version skew where a new extension was added to the availability list before its archive metadata was published; partially failed extension upload; hand-crafted RemoteExtSpec in tests that fills the lists but not extension_data.

Related errors

• library {} is not found
• extension {} is not found
• pg_ctl failed, exit code: {}, stdout: {}, stderr: {}
• no grpc_url for shard {shard_index}
• no libpq_url for shard {shard_index}

AI-assisted analysis of neondatabase/neon@8f60b04da4 (2026-08-16). Data as JSON: /api/errors/ea2c6bab2128c701. Report an issue: GitHub.