`get_column_values` raises `MacroResultAlreadyLoadedError` when using sqlfluff dbt templater or dbt Cloud CLI`

[gabrielbossardi-fd]

Describe the bug

dbt_utils.get_column_values raises MacroResultAlreadyLoadedError when linting with sqlfluff's dbt templater (or running via dbt Cloud CLI) and more than one model calls the macro in the same run.

Steps to reproduce

1. Have two or more models that call dbt_utils.get_column_values — directly or via a wrapper macro.
2. Run sqlfluff lint using the dbt templater against any of those models.
3. The second model to be compiled triggers the error.

Expected results

All models compile and lint successfully without errors.

Actual results

The second model compilation fails with:

dbt.exceptions.MacroResultAlreadyLoadedError:
  The 'statement' result named 'get_column_values' has already been loaded into a variable                                                                                                                     
   
  > in macro default__get_column_values (macros/sql/get_column_values.sql)                                                                                                                                     
  > called by macro get_column_values (macros/sql/get_column_values.sql)

Screenshots and log output

issue-dbt.pdf

System information

The contents of your packages.yml file:

packages:
  - package: dbt-labs/dbt_utils
    version: [">=1.0.0", "<1.4.0"]

Which database are you using dbt with?

• postgres
• redshift
• bigquery
• snowflake
• other (specify: Databricks)

The output of dbt --version:

> dbt --version                                                                                                py rrs 14:58:43
Core:
  - installed: 1.11.6
  - latest:    1.11.8 - Update available!

  Your version of dbt-core is out of date!
  You can find instructions for upgrading here:
  https://docs.getdbt.com/docs/installation

Plugins:
  - databricks: 1.11.6 - Up to date!
  - spark:      1.10.1 - Up to date!

Additional context

Root cause: default__get_column_values uses a hardcoded statement name:

  {%- call statement('get_column_values', fetch_result=true) %}
      ...                                                                                                                                                                                                      
  {%- endcall -%}
  {%- set value_list = load_result('get_column_values') -%}                                                                                                                                                    

Under dbt Core, each model gets a fresh Jinja context so the name never clashes. Under dbt Cloud CLI and sqlfluff's dbt templater, models share a single compilation context. The second model to call this macro finds 'get_column_values' already registered in the results store and crashes.

Suggested fix: Replace call statement / load_result with run_query, which manages its own internal naming and never conflicts across calls.

Are you interested in contributing the fix?

Yes. Fix is a straightforward swap of call statement/load_result for run_query in macros/sql/get_column_values.sql.

[Harish-Ranjith]

I'd like to work on this. The collision here happens because statement() uses a hardcoded name in global context - planning to replace with run_query(). Is this approach still valid and is the issue still open?