astronomer/astronomer-cosmos

Bug description When Cosmos invokes dbt in-process via InvocationMode.DBT_RUNNER, dbt's flags.INVOCATION_COMMAND resolves to the host process's command line — e.g. the Celery worker startup command — rather than the dbt command Cosmos actually ran. Users who log {{ flags.INVOCATION_COMMAND }} from an on-run-end hook (or via packages such as dbt_artifacts / Elementary that persist invocation metadata) get rows like: dbt celery worker --queues dbt-producer-queue -c 6 --without-gossip --without-mingle instead of the expected: dbt --log-format json --debug build -s tag:MY_TAG --vars {"dag_id": "..."} --target PROD This makes the invocation-command column useless for auditing which dbt selector / target / vars produced a given run. Root cause dbt-core builds the value from sys.argv, unconditionally, with no dbtRunner-aware path (dbt/cli/flags.py, dbt-core 1.11.x — same in earlier 1.x): # Add entire invocation command to flags object.__setattr__(self, "INVOCATION_COMMAND", "dbt " + "

When a profile mapping's required secret is absent from the Airflow connection, Cosmos fails with: cosmos.exceptions.CosmosValueError: Could not find a value for secret field password. The message names neither the profile mapping, the connection, nor where Cosmos looked (cosmos/profiles/base.py:238), so users read it as a stale manifest or a cached profile rather than a connection/mapping mismatch. A common trigger: a Snowflake connection is switched from user/password to key-pair auth, while ProfileConfig still uses SnowflakeUserPasswordProfileMapping — which requires password (cosmos/profiles/snowflake/user_pass.py:24-34) and resolves it from profile_args["password"], then conn.password (base.py:288-317). Both are empty after the switch, and the resulting traceback points at env_vars rather than at the connection. Suggested message SnowflakeUserPasswordProfileMapping could not resolve the required dbt profile field 'password'. Cosmos looked in ProfileConfig(profile_args={'passwor

Description Cosmos converts an Airflow connection into a dbt profiles.yml via the configured profile mapping. The contents of the rendered profile are only logged at INFO when profile caching is disabled — when caching is enabled (the default, since enable_cache_profile = True), only the cache path is logged, not the contents. This is a meaningful diagnostic gap: a substantial class of "Cosmos generates the wrong profile" or "Cosmos drops a connection field" issues can only be confirmed by inspecting the rendered file, which requires either: Toggling AIRFLOW__COSMOS__ENABLE_CACHE_PROFILE=False and re-running, or Shelling into the worker and cat-ing the file under /tmp/cosmos/profile/<hash>/profiles.yml. Both are workable but slow, and on managed/serverless deployments (1) requires a redeploy and (2) is often impossible. Where this happens RenderConfig.ensure_profile (around lines 373-411 at the time of writing): Non-cached branch logs the full contents via logger.info("... with th