hasura/graphql-engine · error · TypecheckIssue

Found a literal value but the argument is a boolean expressi

Error message

Found a literal value but the argument is a boolean expression type '{boolean_expression_type_name}'

What it means

A TypecheckIssue specific to boolean expression support: a literal value was supplied where the argument is declared to use a named boolean expression type (a filter object). Hasura-style boolean expression arguments expect structured comparison objects like {_eq: 1}, not raw literals.

Source

Thrown at v3/crates/metadata-resolve/src/helpers/typecheck.rs:43

}

#[derive(Error, Debug, PartialEq)]
/// Issues that can occur when typechecking a value against an object type
pub enum TypecheckIssue {
    #[error("Expected an object value of type {expected:} but got value {actual:}")]
    ObjectTypeMismatch {
        expected: Qualified<CustomTypeName>,
        actual: serde_json::Value,
    },

    #[error("Typecheck failed for field {field_name:} in object type {object_type:}: {error:}")]
    ObjectTypeField {
        field_name: FieldName,
        object_type: Qualified<CustomTypeName>,
        error: TypecheckError,
    },

    #[error(
        "Found a literal value but the argument is a boolean expression type '{boolean_expression_type_name}'"
    )]
    LiteralValueUsedForBooleanExpression {
        boolean_expression_type_name: Qualified<CustomTypeName>,
    },
}

impl ShouldBeAnError for TypecheckIssue {
    fn should_be_an_error(&self, flags: &open_dds::flags::OpenDdFlags) -> bool {
        match self {
            TypecheckIssue::ObjectTypeField { .. } | TypecheckIssue::ObjectTypeMismatch { .. } => {
                flags.contains(Flag::TypecheckObjectTypeValuesInPresets)
            }
            TypecheckIssue::LiteralValueUsedForBooleanExpression { .. } => {
                flags.contains(Flag::DisallowLiteralsAsBooleanExpressionArguments)
            }
        }
    }

View on GitHub (pinned to 724551b9ae)

Solutions

Replace the literal with a boolean expression object, e.g. {field: {_eq: value}}
Check the argument's declared type in the command and confirm it references the intended boolean expression type

Example fix

// before
where: true

// after
where:
  id:
    _eq: 1

Defensive patterns

Strategy: validation

Validate before calling

fn is_boolean_expression_literal(v: &serde_json::Value) -> bool {
    // boolean expression arguments take operator mappings, not primitives
    v.is_object()
}

Try / catch

if let TypecheckIssue::LiteralValueUsedForBooleanExpression { boolean_expression_type_name } = issue {
    eprintln!("use a comparison object for {boolean_expression_type_name:?}, not a literal");
}

Prevention

Remember filter arguments take operator objects ({_eq: ...})
Document boolean expression shapes for API consumers
Add fixtures covering correct filter usage

When it happens

Trigger: Providing a primitive literal (e.g. where: true or where: 5) as the value of an argument whose type is a boolean expression object type, instead of a comparison mapping.

Common situations: Misunderstanding that a boolean expression argument takes operators ({_eq}, {_gt}, ...) rather than a bare value, or miswiring command argument types in metadata.

Related errors

AI-assisted analysis of hasura/graphql-engine@724551b9ae (2026-08-28). Data as JSON: /api/errors/c842418b382b9b8b. Report an issue: GitHub.