[Bug] WATCHER silently emits NO datasets/assets when profiles.yml uses dbt's documented as_number/as_bool Jinja filters #2948

Astronomer Cosmos Version

1.15.1. Regression from 1.15.0, introduced by #2879 (the fix for #2843).

dbt Core or Fusion version

dbt Core 1.11.11

Versions of dbt adapters

dbt-redshift 1.10.1

LoadMode

DBT_LS_MANIFEST

ExecutionMode

WATCHER

InvocationMode

SUBPROCESS

airflow version

3.2.1

Operating System

Amazon Linux

If a you think it's an UI issue, what browsers are you seeing the problem on?

No response

Deployment

Amazon (AWS) MWAA

Deployment details

No response

What happened?

Our profiles.yml uses dbt's documented profiles.yml filters on numeric fields, e.g.

threads: "{{ env_var('DBT_THREADS', 4) | as_number }}"

(as_number/as_bool are documented specifically for profiles.yml:
https://docs.getdbt.com/reference/dbt-jinja-functions/as_number. dbt parses and runs
this profile fine.)

After upgrading 1.15.0 → 1.15.1, a WATCHER DbtDag run completes fully green but emits
zero Assets/dataset events — for every model, not just affected fields. Nothing in
any task log at INFO level; downstream asset-scheduled DAGs never trigger.

Cause: #2879 renders every profile string field through a bare jinja2.Template that
knows none of dbt's filters. | as_number raises
TemplateAssertionError: No filter named 'as_number', which the broadened
except TemplateError in get_dataset_namespace swallows (DEBUG log only) and turns
into return None — and None disables dataset emission for the entire run. A filter
on a field the namespace resolvers never even read (threads, connect_timeout) kills
emission for every model.

Expected: the 1.15.0 behavior (datasets emitted), with #2879's rendering applied
per-field so an unrenderable irrelevant field can't abort namespace derivation — and a
WARNING, not a DEBUG line, if derivation genuinely fails.

Relevant log output

How to reproduce

Standalone, no Airflow run needed. profiles.yml (host is a plain literal; only
threads uses a dbt filter):

repro:
  target: dev
  outputs:
    dev:
      type: postgres
      host: localhost
      port: 5432
      user: postgres
      password: postgres
      dbname: postgres
      schema: public
      threads: "{{ env_var('DBT_THREADS', 4) | as_number }}"

from cosmos.config import ProfileConfig
from cosmos.dataset import get_dataset_namespace

pc = ProfileConfig(profile_name="repro", target_name="dev",
                   profiles_yml_filepath="/path/to/profiles.yml")
print(get_dataset_namespace(pc))
# 1.15.0 -> "postgres://localhost:5432"   (datasets emitted)
# 1.15.1 -> None                          (emission skipped for the whole run)

Anything else :)?

Root cause: _get_profile_dict (dataset.py:146, added by #2879) renders every
string field via _resolve_env_var (cosmos/dbt/project.py:44-62 — bare
jinja2.Template, only env_var in context). The compile-time TemplateAssertionError
is caught by the broadened except (dataset.py:170), logged at DEBUG, and returned as
None ⇒ producer sets _dataset_namespace = None (watcher.py:472-474) ⇒ no outlet URIs
for any model. 1.15.0 emitted for this profile; 1.15.1 emits nothing, silently.

Proposed fix (I'd like to submit a PR):

1. Render per-field with fallback — on TemplateError, keep the raw value, log a
   WARNING, continue. The namespace resolvers only read host/port-style keys, so
   threads/connect_timeout failures become harmless.
2. Register dbt's profiles.yml filters (as_number, as_bool, as_text, as_native)
   in _resolve_env_var's environment — dbt's own text environment implements them as
   identity functions, sufficient here since Cosmos renders to strings.
3. Raise the swallow in get_dataset_namespace from DEBUG to WARNING — "all asset
   emission disabled" should be visible at default log levels.

Regression tests: literal host + as_number on threads ⇒ namespace resolves;
unrenderable field ⇒ raw value kept + WARNING.

Workaround for affected users: replace dbt-only filters with standard Jinja2 ones dbt
also accepts, e.g. | as_number → | int for integer fields.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Contact Details

ignaskr@gmail.com