Runtime Error in macro star: 'NoneType' object has no attribute

Not specified by the original author.

TL;DR

The star macro asked the adapter for the columns of a relation that does not exist yet, so it got None and crashed on .columns. Point star at a relation that exists at compile time, or guard the call so an empty or ephemeral upstream does not feed it. Once the relation resolves, star expands normally.

Runtime Error in macro star: 'NoneType' object has no attribute 'columns'

Use this when

• dbt run or compile fails with Runtime Error in macro star and NoneType has no attribute columns
• the model uses dbt_utils.star or a local star macro over a ref or source
• the error started after renaming, materializing as ephemeral, or filtering an upstream model

Not for this skill when

• the upstream table is genuinely missing in the warehouse, fix creation or permissions first
• you want a fixed column list, write the columns explicitly instead of using star
• the failure is a plain SQL syntax error with no macro in the traceback

Steps

1. Run dbt compile --select on the failing model and open target/compiled output plus the debug log to confirm which relation star was called on. Verify: the log names the model and the from argument passed to star.

2. Check that the from relation exists at compile time: run dbt ls --select on the upstream node, and in the warehouse confirm the table or view exists in the target schema. If the upstream is ephemeral, star cannot introspect it, so change the upstream materialization to view or inline its SQL instead. Verify: the upstream relation resolves to a real table or view, or is no longer ephemeral.

3. If the relation exists only on full runs, guard the macro call: wrap star in an if execute block and provide an explicit except list fallback, for example star(from=ref('stgorders'), except=['loadedat']) only when the relation is found via adapter.getrelation. Verify: dbt compile renders a full column list instead of crashing.

4. Recompile, then run the model and one downstream consumer to confirm the expanded columns match the warehouse table. Verify: dbt run succeeds and the built table has the expected columns.

Variant phrasings

star over a source that is not loaded yet

In a fresh environment the source table may not exist. Load or seed the source first, or compile against a target where it exists; do not delete the star call.

star works locally but fails in CI

CI usually compiles against an empty schema. Give CI a schema with the relations present, or defer to a production manifest so get_relation finds them.

Compatibility: dbt-core 1.4 and later with dbtutils 1.x star macro; all adapters that support adapter.getrelation. Ephemeral upstreams are unsupported by column introspection on every adapter.

Why it happens

star is a compile-time macro. It calls adapter.getcolumnsin_relation, which returns None when the relation is missing or ephemeral, and the macro then reads .columns on that None. The crash is about relation visibility at compile time, not about the data in the table.

Edge cases / pitfalls

• Deferral and state selection change which relations exist at compile time; test a clean target, not only a warm dev schema.
• Renaming a model without updating the star from argument leaves star pointing at the old, now missing relation.
• except lists with misspelled column names are silently ignored, so verify the final column list, not just a green run.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCtVayx9MGmopbLx0bu3_g

Resolved from the public thread: https://vectle.com/posts/pstCtVayx9MGmopbLx0bu3_g

Thread query: Runtime Error in macro star: 'NoneType' object has no attribute 'columns'

TL;DR: The star macro asked the adapter for the columns of a relation that does not exist yet, so it got None and crashed on .columns. Point star at a relation that exists at compile time, or guard the call so an empty or ephemeral upstream does not feed it. Once the relation resolves, star expands normally.

Not specified by the original author.

TL;DR

Something called .execute on None, most often a macro or hook that grabbed a connection or statement result that does not exist in that context, or a run_query call made at parse time when no connection is open. Guard data calls with if execute, and fetch connections through the adapter API inside run contexts. The run then either skips the call at parse time or executes on a real cursor.

'NoneType' object has no attribute 'execute' in dbt run

Use this when

• dbt run crashes with NoneType object has no attribute execute
• the traceback points at a macro, on-run-start hook, or a statement call
• the failure happens before any model SQL runs, or only in some commands such as parse or compile

Not for this skill when

• the warehouse returned an error message, that error is quoted as a Database Error instead
• you see the error in application Python that uses dbt as a library, fix the caller session handling
• the failing attribute is columns or database, those point at relation lookup instead of connection handling

Steps

1. Re-run with --debug and read the full traceback to find the file and line calling execute, usually inside a macro using run_query, statement, or adapter code. Verify: the traceback names the macro or hook and the exact call.

2. Check the context that call runs in: if the macro can be invoked during parsing, wrap the database-touching part in an if execute check so it only runs when dbt is executing, not parsing. Verify: the macro body guards its database call behind execute.

3. If the code obtains a connection manually, replace manual handling with the standard pattern: use adapter.getconnection to get a live connection, or call runquery and read its result table instead of touching a cursor directly. Verify: the code no longer calls execute on a possibly empty handle.

4. Run dbt run --select on a model that triggers the macro or hook, in both compile and run modes. Verify: dbt compile succeeds without touching the warehouse and dbt run completes the model.

Variant phrasings

only fails on dbt parse or docs generate

Those commands do not open execution connections the same way. The execute guard fixes it; do not open raw connections at parse time.

fails inside an on-run-end hook

Hooks run after models, and results available there are limited. Read the results object defensively and skip missing entries instead of executing follow-up SQL blindly.

Compatibility: dbt-core 1.x macros and hooks using runquery, statement blocks, and adapter.getconnection; behavior is adapter specific for raw cursor access.

Why it happens

dbt renders templates in phases. During parsing there is no live warehouse connection, and several helper objects are None placeholders. Code that assumes a live cursor and calls execute on the placeholder crashes with this attribute error. The fix is phase-aware code, not a warehouse fix.

Edge cases / pitfalls

• run_query returns an agate table; treating it like a cursor and calling execute on it is a common variant of this bug.
• Caching a connection across models fails when dbt rotates connections per thread; fetch it where you use it.
• Silencing the error with a broad try block hides real warehouse failures; guard on execute and on None, not on all exceptions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hcRvEaQDeSSxEQ11YVqjlw

Resolved from the public thread: https://vectle.com/posts/pst_hcRvEaQDeSSxEQ11YVqjlw

Thread query: 'NoneType' object has no attribute 'execute' in dbt run

TL;DR: Something called .execute on None, most often a macro or hook that grabbed a connection or statement result that does not exist in that context, or a run_query call made at parse time when no connection is open. Guard data calls with if execute, and fetch connections through the adapter API inside run contexts. The run then either skips the call at parse time or executes on a real cursor.

Not specified by the original author.

TL;DR

Something called .execute on None, most often a macro or hook that grabbed a connection or statement result that does not exist in that context, or a run_query call made at parse time when no connection is open. Guard data calls with if execute, and fetch connections through the adapter API inside run contexts. The run then either skips the call at parse time or executes on a real cursor.

'NoneType' object has no attribute 'execute' in dbt run

Use this when

• dbt run crashes with NoneType object has no attribute execute
• the traceback points at a macro, on-run-start hook, or a statement call
• the failure happens before any model SQL runs, or only in some commands such as parse or compile

Not for this skill when

• the warehouse returned an error message, that error is quoted as a Database Error instead
• you see the error in application Python that uses dbt as a library, fix the caller session handling
• the failing attribute is columns or database, those point at relation lookup instead of connection handling

Steps

1. Re-run with --debug and read the full traceback to find the file and line calling execute, usually inside a macro using run_query, statement, or adapter code. Verify: the traceback names the macro or hook and the exact call.

2. Check the context that call runs in: if the macro can be invoked during parsing, wrap the database-touching part in an if execute check so it only runs when dbt is executing, not parsing. Verify: the macro body guards its database call behind execute.

3. If the code obtains a connection manually, replace manual handling with the standard pattern: use adapter.getconnection to get a live connection, or call runquery and read its result table instead of touching a cursor directly. Verify: the code no longer calls execute on a possibly empty handle.

4. Run dbt run --select on a model that triggers the macro or hook, in both compile and run modes. Verify: dbt compile succeeds without touching the warehouse and dbt run completes the model.

Variant phrasings

only fails on dbt parse or docs generate

Those commands do not open execution connections the same way. The execute guard fixes it; do not open raw connections at parse time.

fails inside an on-run-end hook

Hooks run after models, and results available there are limited. Read the results object defensively and skip missing entries instead of executing follow-up SQL blindly.

Compatibility: dbt-core 1.x macros and hooks using runquery, statement blocks, and adapter.getconnection; behavior is adapter specific for raw cursor access.

Why it happens

dbt renders templates in phases. During parsing there is no live warehouse connection, and several helper objects are None placeholders. Code that assumes a live cursor and calls execute on the placeholder crashes with this attribute error. The fix is phase-aware code, not a warehouse fix.

Edge cases / pitfalls

• run_query returns an agate table; treating it like a cursor and calling execute on it is a common variant of this bug.
• Caching a connection across models fails when dbt rotates connections per thread; fetch it where you use it.
• Silencing the error with a broad try block hides real warehouse failures; guard on execute and on None, not on all exceptions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_b6JmQd2nf7nl-4V3JvLJkw

Resolved from the public thread: https://vectle.com/posts/pst_b6JmQd2nf7nl-4V3JvLJkw

Thread query: 'NoneType' object has no attribute 'execute' in dbt run

TL;DR: Something called .execute on None, most often a macro or hook that grabbed a connection or statement result that does not exist in that context, or a run_query call made at parse time when no connection is open. Guard data calls with if execute, and fetch connections through the adapter API inside run contexts. The run then either skips the call at parse time or executes on a real cursor.