Invalid client property. Should have been a aws-bedrock prop

Error message

Invalid client property. Should have been a aws-bedrock property but got: {}

What it means

resolve_properties resolves the client's property block against the runtime context and expects the result to be the AWSBedrock variant. If the resolved properties are any other client type (the provider string didn't map to aws-bedrock, or the wrong properties block was matched), it bails. This is an internal consistency check between the configured provider and the resolved property enum.

Source

Thrown at engine/baml-runtime/src/internal/llm_client/primitive/aws/aws_client.rs:189

fn resolve_properties(
    provider: &ClientProvider,
    properties: &UnresolvedClientProperty<()>,
    ctx: &RuntimeContext,
) -> Result<ResolvedAwsBedrock> {
    let strict = {
        #[cfg(target_arch = "wasm32")]
        {
            false
        }

        #[cfg(not(target_arch = "wasm32"))]
        true
    };
    let properties = properties.resolve(provider, &ctx.eval_ctx(strict))?;

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

    Ok(props)
}

// Helper function to convert serde_json::Value to aws_smithy_types::Document
fn serde_json_to_aws_document(value: serde_json::Value) -> Document {
    match value {
        serde_json::Value::Null => Document::Null,
        serde_json::Value::Bool(b) => Document::Bool(b),
        serde_json::Value::Number(n) => {
            if n.is_i64() {
                Document::Number(aws_smithy_types::Number::NegInt(n.as_i64().unwrap()))
            } else if n.is_u64() {
                Document::Number(aws_smithy_types::Number::PosInt(n.as_u64().unwrap()))

View on GitHub (pinned to bd85ce9dee)

Solutions

Set the client's provider to exactly 'aws-bedrock' in the BAML client definition or ClientRegistry.
Check that client options overrides (set_client_options / registry) are not swapping the provider type for this client name.
Log properties.name() from the error message to see which property type actually resolved, and fix the mismatched definition.

Example fix

// before
client<llm> Bedrock {
  provider "aws"
  options { ... }
}
// after
client<llm> Bedrock {
  provider "aws-bedrock"
  options { ... }
}

Defensive patterns

Strategy: validation

Validate before calling

# verify provider before constructing the client
if client_registry.provider(client_name) != 'aws-bedrock':
    raise ValueError(f"client {client_name} must use provider aws-bedrock")

Try / catch

match AwsClient::new(...) {
    Err(e) if e.to_string().contains("Should have been a aws-bedrock property") => {
        // fix provider in client definition / registry and retry
    }
    other => other?,
}

Prevention

Use the exact provider string 'aws-bedrock' in client definitions
Avoid overriding provider via dynamic client options unless intentional
Keep one client definition per provider to prevent mismatches

When it happens

Trigger: Constructing an AwsClient (via dynamic_new or new) whose resolved provider/properties are not aws-bedrock — e.g. a client named/typed as another provider being routed through the AWS client constructor, or a BAML client-define whose provider suffix mis-resolves after client options overrides.

Common situations: Programmatically building clients with ClientRegistry where the provider string is misspelled or options override the provider; using a generic 'aws' provider value instead of aws-bedrock; mixing client definitions in multi-provider setups.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

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