@izeigerman thank you for the review– addressed all comments. Planning to merge once CI's green.

@izeigerman since my last comment in this PR, I discovered a bug and refactored my approach to patch it– can you please take another look when you find some bandwidth?

The bug

Given the following macros:

from sqlmesh import macro

@macro()
def macro1(evaluator):
    return evaluator.var("foo")

@macro(metadata_only=True)
def macro2(evaluator, var_value):
    return 1

and this model:

MODEL (
  name test_model,
  kind FULL,
);

SELECT
  @macro1() AS col,
  @macro2(@foo) AS col2

I verified that @foo was being marked as metadata-only, despite it being referenced within macro1, which is not metadata-only:

>>> from sqlmesh import Context
>>> ctx = Context()
>>> ctx.models['"test_model"'].python_env
{'macro1': Executable<payload: def macro1(evaluator):
    return evaluator.var('foo'), name: macro1, path: macros/test.py>, 'macro2': Executable<payload: def macro2(evaluator, var_value):
    return 1, name: macro2, path: macros/test.py, is_metadata: True>, '__sqlmesh__vars__metadata__': Executable<payload: {'foo': "'id'"}, kind: value, is_metadata: True>}

Root cause

The problematic logic was located here. The value of used_variables was {'foo': False} for the above project, while the value of macro_funcs_by_used_var was defaultdict(<class 'set'>, {'foo': {'macro2'}}).

This meant that used_variables.get(used_var) would yield false and so we checked the all(...) condition that only looked at macro2, which is indeed metadata-only but that is not enough to mark foo as metadata-only.

Fix

I addressed the above issue in this commit. Below is my analysis that led to this refactor:

Terminology

• Metadata status: the value of is_metadata for an Executable instance
• Metadata-only: when a variable or macro Executable has is_metadata set to True
• Metadata expression: expressions such as audits (...), or virtual statement blocks that only affect the metadata hash
• Direct variable reference: a variable that is referenced directly in SQL code
• Indirect variable reference: a variable that is referenced indirectly in SQL code, e.g., an invoked macro references it internally

Observations

1. We can always infer the metadata status of an indirect variable reference; it inherits it from the macro that references it.

2. We can't determine the metadata status of direct variable references that are under some macro function call until later. The reason is that the macro definition walking happens after we analyze the model's ASTs, so only after that is done we can have the full picture w.r.t. the metadata status of said macro call, which affects the metadata status of the variable itself. For example, a variable reference that is used as an argument of a metadata-only macro is itself metadata-only. The only exception to this rule is when the variable appears in a metadata expression, since everything under it is treated as metadata-only.

3. If there is at least one reference of a variable outside of a metadata expression and not under any macro function call, then that variable is guaranteed to be non-metadata. Otherwise, every reference of said variable may appear in either a metadata expression, or under a macro function call. If there is at least one reference under a macro function call, we must defer the metadata status inference for that variable until after we walk the macro objects and know their metadata statuses. Then, the status of the metadata is all of these statuses combined through conjunction.

... and yet another bug squashed: I realized that only the top-level macro func call matters when it comes to marking variable references under it as metadata or not. Added a test that demonstrates this.