hasura/graphql-engine · error · ConditionError

Serde error: {error}

Error message

Serde error: {error}

What it means

A generic wrapper in the authorization condition evaluator: any (de)serialization failure while parsing/evaluating parts of a permission condition — e.g. deserializing an argument name, expression tree, or comparison value that doesn't match the expected IR shape — is surfaced as ConditionError::SerdeError with the underlying error string.

Source

Thrown at v3/crates/auth/authorization-rules/src/condition.rs:17

//! this is where we evaluate Conditions

use std::fmt::Display;

use hasura_authn_core::{SessionVariableName, SessionVariables};

use crate::ConditionCache;
use metadata_resolve::{
    BinaryOperation, Condition, ConditionHash, Conditions, UnaryOperation, ValueExpression,
};
use open_dds::query::ArgumentName;

#[derive(Debug, PartialEq, Eq, thiserror::Error)]
pub enum ConditionError {
    #[error("Session variable not found: {name}")]
    SessionVariableNotFound { name: SessionVariableName },
    #[error("Serde error: {error}")]
    SerdeError { error: String },
    #[error("Condition {condition_hash} not found")]
    ConditionNotFound { condition_hash: ConditionHash },
    #[error("Expected array or null for right-hand value of contains operation")]
    ExpectedArrayOrNullForContains,
    #[error("Expected number for {side}-hand value of comparison operation")]
    ExpectedNumberForComparison { side: Side },
    #[error(
        "Number for {side}-hand value of comparison operation is outside precision or range of a double-precision float"
    )]
    NumberOutOfRange { side: Side },
    #[error(
        "Tried to combine a predicate with a literal in argument presets for argument {argument_name}"
    )]
    CouldNotCombinePredicateAndLiteralArgumentPresets { argument_name: ArgumentName },
}

// evaluate conditions used in permissions

View on GitHub (pinned to 724551b9ae)

Solutions

  1. Read the embedded `{error}` string — it names the exact field and expected type
  2. Validate/re-apply role permission metadata with the current CLI version (hasura metadata apply / build)
  3. Regenerate the metadata rather than hand-editing condition expressions
  4. Check for version skew between the CLI that produced the metadata and the engine evaluating it

Example fix

# before
comparison_expressions:
  - name: by_user
    expression: { column: user_id, value: { session: x_hasura_user_id } }
# after (match the documented IR shape)
comparison_expressions:
  - name: by_user
    expression:
      and:
        - { column: user_id, operator: eq, value: { session: x_hasura_user_id } }
Defensive patterns

Strategy: try-catch

Validate before calling

// Validate metadata against the project's schema before apply
// e.g. hasura3 metadata export + CI JSON-schema check of comparison expressions

Type guard

null

Try / catch

match cond_eval { Err(ConditionError::SerdeError { error }) => { log::warn!("bad condition shape: {error}"); deny_or_fix() } _ => ... }

Prevention

When it happens

Trigger: Metadata containing a comparison/expression value whose JSON shape doesn't deserialize into the condition IR: wrong type for an operand, malformed expression objects, or version-skewed metadata generated by a different CLI/engine version.

Common situations: Hand-edited or tool-generated metadata with subtly wrong shapes; upgrading the platform so condition IR schemas changed while old metadata remains; passing complex objects where scalars are expected in rules.

Related errors

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