dbt run error: NoneType object is not subscriptable

TL;DR

Something returned None and the code indexed into it like result['key']. Find the call that can return None (often adapter.get_relation or a macro returning nothing), guard it with an if check, and only subscript after you know it is real.

Error

dbt run error: NoneType object is not subscriptable

Steps

1. Get the traceback with --debug. It names the file and line doing the subscription, e.g. result['rows'] where result is None. Expected: You have the exact line and the variable that is None.

2. Trace the variable's source: usually a function or macro that returns None on a miss, like adapter.get_relation for a nonexistent relation, or a python model helper with an early return. Expected: You can name the call that produced None.

3. Guard it: if result is None: handle the miss (raise a clear error, or default), and only subscript inside the else branch. In jinja macros, check {% if result %} first. Expected: The None path is handled explicitly instead of crashing.

4. Re-run the model or macro, plus any other callers of the same helper. Expected: Clean run; the miss case now produces a clear message or a default.

When to use

• dbt fails with NoneType object is not subscriptable in a python model or macro
• after adding a lookup (get_relation, var dict access) that can miss
• a macro that returns nothing on some code path

When not to use

• dict object has no attribute (the object exists, a key is missing, different fix)
• warehouse SQL errors with no python traceback
• the error is in dbt core internals with no project code in the trace (then check versions)

Tool compatibility

• dbt python models (1.3+) and jinja macros both hit this
• --debug is required to see the project-code line in the traceback
• dbt Cloud run logs include the traceback too

Variant phrasings

NoneType object is not subscriptable in a snapshot

Usually adapter.get_relation returning None for the target table on first run. Guard the None case as table-not-yet-created.

error inside dbt-utils macro

Check your arguments first; dbt-utils macros return None-ish results when given an empty relation list. Then pin the package version.

Why it happens

dbt helpers return None to signal not found, and jinja/python happily pass that along until something subscripts it. The crash site is rarely the bug site; the bug is the unhandled miss one call up the stack.

Edge cases

• In jinja, {% set x = none_value['k'] %} fails the same way; jinja None subscripting raises like python.
• If the None comes from dbt internals after an upgrade, check the adapter version matrix before rewriting project code.

Provenance

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