dbt-labs/dbt-core · error
Unknown method on adapter object: '{name}'
Error message
Unknown method on adapter object: '{name}' What it means
The adapter object exposed to Jinja dispatches method calls by name against a fixed match table. Any method name not present in that table raises `UnknownMethod` with `Unknown method on adapter object: '{name}'`. This is a typo/version-coverage guard: the requested adapter method is not implemented (or not yet registered) for this adapter object.
Source
Thrown at crates/dbt-adapter/src/adapter/mod.rs:4386
})?
.downcast_object::<AgateTable>()
.ok_or_else(|| {
minijinja::Error::new(
minijinja::ErrorKind::InvalidOperation,
"get_csv_data: argument must be an AgateTable",
)
})?;
self.get_csv_data(table)
}
"get_credentials" => self.get_credentials(args),
"render_equals" => {
let iter = ArgsIter::new(name, &["expr1", "expr2"], args);
let expr1 = iter.next_arg::<&str>()?;
let expr2 = iter.next_arg::<&str>()?;
iter.finish()?;
self.render_equals(state, expr1, expr2)
}
_ => Err(minijinja::Error::new(
minijinja::ErrorKind::UnknownMethod,
format!("Unknown method on adapter object: '{name}'"),
)),
}
}
/// ClickHouse: `adapter.get_credentials(connection_overrides)` — connection
/// parameters for dictionary SOURCE clauses. See [AdapterImpl::get_credentials].
pub fn get_credentials(&self, args: &[Value]) -> Result<Value, minijinja::Error> {
let iter = ArgsIter::new("get_credentials", &["connection_overrides"], args);
let overrides = iter.next_arg::<Option<&Value>>()?;
iter.finish()?;
match &self.inner {
Typed { adapter, .. } => {
Ok(adapter.get_credentials(overrides.unwrap_or(&Value::UNDEFINED)))
}
Parse(_) => Ok(empty_map_value()),
}View on GitHub (pinned to 0267ce9170)
Solutions
- Check the spelling of the method name against the adapter's implemented method list (the match table in crates/dbt-adapter/src/adapter/mod.rs).
- If the method is legitimately missing, implement/override it via the adapter's dispatch or use an available equivalent (e.g. `dispatch('...')` to a macro implementation).
- Guard adapter-specific calls in macros behind adapter-type checks so ClickHouse-only methods are not invoked elsewhere.
- Verify macro/adapter version compatibility after upgrading dbt or the adapter.
Example fix
// before (Jinja)
{% set cols = adapter.get_columns_in_relation_(relation) %}
// after
{% set cols = adapter.get_columns_in_relation(relation) %} Defensive patterns
Strategy: fallback
Validate before calling
{# Jinja: feature-detect the method before relying on it #}
{% set has_method = adapter is mapping and method_name in adapter %} Try / catch
{# Jinja: wrap risky adapter calls with a dispatch fallback #}
{% set result = adapter.dispatch('get_columns_in_relation')(relation) %}
{# or #}
{% if execute and adapter_type == 'clickhouse' %}
{{ adapter.clickhouse_only_method() }}
{% endif %} Prevention
- Verify method names against the adapter's dispatch table before use.
- Use `adapter.dispatch('<name>')` instead of hard-coding adapter-specific methods.
- Guard adapter-specific calls with `adapter_type` checks.
- After upgrades, grep custom macros for adapter.* calls and confirm each still exists.
When it happens
Trigger: A Jinja macro calls `adapter.some_method(...)` where `some_method` is misspelled, is dbt-core-specific and not ported to this Rust adapter, or is adapter-specific (e.g. a ClickHouse-only macro running against another adapter's object).
Common situations: Ported dbt-core macros calling Python adapter APIs that have no Rust equivalent yet; typos in custom macros; materializations shared across adapters invoking methods only some adapters implement; version drift after upgrading where a method was renamed or removed.
Related errors
- Unknown method on ColumnStatic: '{name}'
- describe_dynamic_table is not supported by the {} adapter
- describe_interactive_table is not supported by the {} adapte
- invalid return value
- target is not set in state
AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07).
Data as JSON: /api/errors/5a47b3540cdf310d.
Report an issue: GitHub.