dbt-labs/dbt-core · error · ExitWithStatus

{warn_string}

Error message

{warn_string}

What it means

When a Jinja template calls dbt's `warn(msg)` and the project's warn-error options promote that warning code to an error (`WarnErrorDecision::UpgradeToError`), the library converts the warning into an `ExitWithStatus` error carrying the warning text. This is intentional behavior: `--warn-error` style configuration turns warnings into hard failures.

Source

Thrown at crates/dbt-jinja-utils/src/functions/base.rs:1125

                    FsError::new_no_backtrace(ErrorCode::JinjaWarn, warn_string.clone())
                        .with_location(CodeLocationWithFile::new(
                            current_span.start_line,
                            current_span.start_col,
                            current_span.start_offset,
                            current_file_path,
                        )),
                );

                // Emit through the warn path even when warn-error upgrades it because tracing
                // handles the event level upgrade for dbt-facing outputs.
                let warn_error_decision = self
                    .warn_error_options
                    .decision_for_error_code(warning.code)
                    == WarnErrorDecision::UpgradeToError;
                emit_warn_log_from_fs_error(*warning);

                if warn_error_decision {
                    return Err(Error::new(ErrorKind::ExitWithStatus, warn_string));
                }

                Ok(Value::UNDEFINED)
            }
            // (msg, node=None)
            "raise_compiler_error" => {
                let mut args = ArgParser::new(args, None);
                let message = args.get::<String>("msg")?;
                if let Some((node_id, file_path)) = node_metadata_from_state(state) {
                    Err(Error::new(
                        ErrorKind::InvalidOperation,
                        format!(
                            "Compilation Error for {} from {}: {}",
                            node_id,
                            file_path.display(),
                            message
                        ),
                    ))

View on GitHub (pinned to 0267ce9170)

Solutions

1. Remove the warning's code from the warn-error include list (or add it to exclude) in warn_error_options
2. Fix the underlying condition the warn() call reports so it is never triggered
3. Drop the `--warn-error` flag if promotion to error is not desired

Example fix

// before (dbt_project.yml / CLI)
flags: warn_error: true
// after
flags:
  warn_error_options:
    include: [other-warning-code]  # exclude the code being raised

// inspect decision before raising:
// warn_error_options.decision_for_error_code(code) != UpgradeToError

// CLI: capture non-zero exit and inspect stderr for the warn_string
match run_dbt() {
    Err(e) if e.to_string().contains("warn") => warn!("warning promoted to error: {e}"),
    other => other?,
}

When it happens

Trigger: A template calls `warn(...)` (or `exceptions.warn`) while `warn_error_options.decision_for_error_code` maps the warning's code to `UpgradeToError`.

Common situations: Running with `--warn-error` or `--warn-error-options` include/exclude settings that include the raised warning code, causing an otherwise benign warning to abort the run.

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

• `http_status_as_error` is not enabled.
• RelationConfigBaseObject does not support method: {}
• {} relation creation from Jinja values
• group_by with function key
• describe_dynamic_table is not supported by the {} adapter

AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/577d3c85b99db931. Report an issue: GitHub.