hasura/graphql-engine · error · Error

{errors}

Error message

{errors}

What it means

Aggregate error emitted by the metadata resolver when more than one error occurs while resolving metadata (e.g. resolving a subgraph with many invalid entries). Instead of failing on the first problem, the resolver collects errors wrapped with their context and reports them together, separated by newlines. It exists so users see all metadata issues in one pass rather than fixing them one at a time.

Source

Thrown at v3/crates/metadata-resolve/src/types/error.rs:296

        #[from] data_connector_scalar_types::DataConnectorScalarTypesError,
    ),
    #[error("{0}")]
    ArgumentError(#[from] arguments::NamedArgumentError),
    #[error("{0}")]
    ModelGraphqlError(#[from] models_graphql::ModelGraphqlError),
    #[error("{warning_as_error}")]
    CompatibilityError { warning_as_error: crate::Warning },
    #[error("{0}")]
    LifecyclePuginError(#[from] plugins::PluginValidationError),

    #[error("{0}")]
    ViewError(#[from] views::Error),
    #[error("{0}")]
    SqlSchemaAliasError(#[from] sql_schema_aliases::SqlSchemaAliasError),
    #[error("unknown view '{view_name}' in view permissions")]
    UnknownView { view_name: Qualified<ViewName> },

    #[error("{errors}")]
    MultipleErrors {
        errors: SeparatedBy<WithContext<Error>>,
    },
}

pub trait ShouldBeAnError {
    fn should_be_an_error(&self, flags: &flags::OpenDdFlags) -> bool;
}

pub trait ContextualError {
    fn create_error_context(&self) -> Option<error_context::Context>;
    fn add_context_if_exists(self) -> WithContext<Self>
    where
        Self: Sized,
    {
        match self.create_error_context() {
            Some(context) => WithContext::Contextualised {
                error: self,

View on GitHub (pinned to 724551b9ae)

Solutions

1. Read the full `{errors}` list: each line names a specific metadata problem with its file/context — fix each one individually
2. Re-run metadata resolve/build after each fix; the list shrinks as you go
3. Use `hasura metadata resolve` (or the CLI lint/validate command) in CI to catch these before apply
4. If a single underlying error dominates, fix that first — later errors are often cascading from it

Example fix

# before: subgraph-metadata.yaml has several bad references
# (unknown command, invalid relationship, unknown type)
# after: fix each entry reported in the MultipleErrors list
relationships:
  - name: author
    source: authors   # now a valid model name
commands:
  - name: myCommand
    target: myModel   # now a valid model name

// Match on the aggregate variant and iterate the collected errors
match result {
    Err(Error::MultipleErrors { errors }) => {
        for e in errors.iter() {
            eprintln!("metadata error: {e}");
        }
    }
    Err(e) => eprintln!("metadata error: {e}"),
    Ok(_) => {}
}

When it happens

Trigger: Building/resolving metadata whose resolution pipeline accumulates several sub-errors (invalid types, commands, relationships, etc.) in one resolve cycle; the resolver wraps each underlying Error with WithContext and joins them into this MultipleErrors variant.

Common situations: Running `hasura` metadata build/apply on a subgraph with multiple invalid entries; CI metadata validation surfacing several warnings at once; upgrading Hasura to a version with stricter metadata validation so many previously-ignored issues now collect into one error.

Related errors

• ndc validation error: {0}
• unable to parse server endpoint: %w
• metadata is not consistent: {error}
• function {function_name} is not defined in data connector {d
• could not find a scalar-operanded boolean expression type na

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