## 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.

```text
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('stg_orders'), except=['_loaded_at']) only when the relation is found via adapter.get_relation.
   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 dbt_utils 1.x star macro; all adapters that support adapter.get_relation. Ephemeral upstreams are unsupported by column introspection on every adapter.

## Why it happens

star is a compile-time macro. It calls adapter.get_columns_in_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/pst_CtV_ayx9MGmopbLx0bu3_g