BoundaryML/baml · error · anyhow::Error

Invalid client property. Should have been a openai property

Error message

Invalid client property. Should have been a openai property but got: {}

What it means

This helper resolves an UnresolvedClientProperty and asserts the resolved variant is ResolvedClientProperty::OpenAI. If the property resolves to any other provider variant (e.g. AWS, Google, Anthropic), the pattern match fails and the error reports the actual variant name. It is an internal type/assertion guard used by the OpenAI property resolution path.

Source

Thrown at engine/baml-runtime/src/internal/llm_client/primitive/openai/properties/mod.rs:15

use internal_llm_client::{
    openai::ResolvedOpenAI, ClientProvider, ResolvedClientProperty, UnresolvedClientProperty,
};

use crate::RuntimeContext;

pub fn resolve_properties(
    provider: &ClientProvider,
    properties: &UnresolvedClientProperty<()>,
    ctx: &RuntimeContext,
) -> anyhow::Result<ResolvedOpenAI> {
    let properties = properties.resolve(provider, &ctx.eval_ctx(false))?;

    let ResolvedClientProperty::OpenAI(props) = properties else {
        anyhow::bail!(
            "Invalid client property. Should have been a openai property but got: {}",
            properties.name()
        );
    };

    Ok(props)
}

View on GitHub (pinned to bd85ce9dee)

Solutions

Check the client definition in clients.baml and ensure the provider is an OpenAI-family provider (openai / azure-openai / openai-generic) matching the property block.
Verify the error's trailing `{}` value — it names the property actually resolved — and fix the provider/property mismatch.
If constructing clients programmatically, pass the property belonging to the OpenAI provider to this resolver.
Upgrade baml to align resolver dispatch with newly added providers if using a recent provider type.

Example fix

// before (mismatch)
client<MyClient> {
  provider openai
  options { ... } // actually a property resolved as AwsBedrock
}
// after
client<MyClient> {
  provider openai
  options {
    model "gpt-4o"
    api_key env.OPENAI_API_KEY
  }
}

Defensive patterns

Strategy: type-guard

Validate before calling

// Ensure the provider is OpenAI-family before resolving via the OpenAI path
fn is_openai_provider(provider: &str) -> bool {
    matches!(provider, "openai" | "azure-openai" | "openai-generic")
}

Type guard

fn as_openai_props(p: &ResolvedClientProperty) -> Option<&ResolvedOpenAI> {
    match p {
        ResolvedClientProperty::OpenAI(props) => Some(props),
        _ => None,
    }
}

Prevention

Keep provider strings in clients.baml consistent with the options block shape.
Regenerate generated BAML clients after any provider change.
Match on ResolvedClientProperty variants explicitly instead of assuming OpenAI.

When it happens

Trigger: Passing a client property block that is not an OpenAI-family provider (e.g. `aws`, `google-ai`, or a named policy/wrapper property) into the OpenAI resolve_properties path — typically from miswired internal client construction or a provider string that dispatched to the OpenAI resolver with a non-OpenAI property.

Common situations: A typo or mismatch between the provider label and the property block in clients.baml; programmatic client construction where the wrong UnresolvedClientProperty is handed to the OpenAI resolver; version mismatches where a new provider variant reaches an older resolver.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/f9a7d0469d51c42b. Report an issue: GitHub.