Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can't seem to inject vars via operator_args #544

Closed
set5think opened this issue Sep 18, 2023 · 3 comments · Fixed by #735
Closed

can't seem to inject vars via operator_args #544

set5think opened this issue Sep 18, 2023 · 3 comments · Fixed by #735
Labels
bug Something isn't working priority:high High priority issues are blocking or critical issues without a workaround and large impact
Milestone

Comments

@set5think
Copy link

Hi, I'm running cosmos 1.1.1, and am reading the docs and code, and am using basically the same code minus values, but no matter what I do, the dbt command is never generates with the dbt vars I pass through operator_args. When I inspect cosmos/graph.py, I don't see where operator_args is ever used to inject settings from it into the dbt the command. I only see it to populate a class called LegacyDbtProject and then just in the class signature.

Is there a different way to inject dbt vars not using operator_args?

Thanks,

-Hassan

@tatiana
Copy link
Collaborator

tatiana commented Sep 27, 2023

HI @set5think , thanks for posting the issue!

Have you tried the following: https://astronomer.github.io/astronomer-cosmos/configuration/operator-args.html?

Please give a step-by-step for us to reproduce the issue.

@fabiomx
Copy link
Contributor

fabiomx commented Oct 26, 2023

Hi,

I have the same issue. I can reproduce it with DBT_LS load mode.

operator_args = {
    "vars": {"SNOWFLAKE_DATABASE": database}
}


def get_render_config(schedule_tag: str):
    return RenderConfig(load_method=LoadMode.DBT_MANIFEST,
                        test_behavior=TestBehavior.AFTER_EACH,
                        select=[f"tag:{schedule_tag}"]
                        )


@dag(dag_id="dbt_hourly", schedule_interval=timedelta(hours=1), default_args=default_args, catchup=False)
def dbt_hourly_dag():
    start = EmptyOperator(task_id="start")

    dbt_tg = DbtTaskGroup(
        project_config=project_config,
        profile_config=profile_config,
        execution_config=execution_config,
        default_args=default_args,
        operator_args=operator_args,
        render_config=get_render_config("hourly")

    )

    end = EmptyOperator(task_id="end")

    start >> dbt_tg >> end

I get:

Broken DAG: [/home/airflow/gcs/dags/dbt_cosmos.py] Traceback (most recent call last):
  File "/opt/python3.8/lib/python3.8/site-packages/cosmos/dbt/graph.py", line 132, in load
    load_method[method]()
  File "/opt/python3.8/lib/python3.8/site-packages/cosmos/dbt/graph.py", line 255, in load_via_dbt_ls
    raise CosmosLoadDbtException(f"Unable to run dbt ls command due to the error:\n{details}")
cosmos.dbt.graph.CosmosLoadDbtException: Unable to run dbt ls command due to the error:
�[0m20:27:11  Running with dbt=1.5.4
�[0m20:27:19  Registered adapter: snowflake=1.5.4
�[0m20:27:19  Unable to do partial parsing because saved manifest not found. Starting full parse.
�[0m20:27:31  Encountered an error:
Compilation Error
  Could not render {{var('SNOWFLAKE_DATABASE')}}: Required var 'SNOWFLAKE_DATABASE' not found in config:
  Vars supplied to <Configuration> = {}

With DBT_MANIFEST, it works fine.

Also, if I set the var in the dbt_project file, I have no issues*, but I need to generate the var dynamically and use it via the vars argument.

*Well, I have the time-out issue mentioned here: #520 (comment), but no more var-related issues.

I'm on Cosmos 1.2.1 / dbt-core 1.5.4, on Google Cloud Composer, local execution mode.

@tatiana tatiana added bug Something isn't working and removed awaiting_response labels Nov 2, 2023
@tatiana tatiana modified the milestones: 1.2.2, 1.3.0 Nov 2, 2023
@tatiana
Copy link
Collaborator

tatiana commented Nov 2, 2023

@fabiomx The issue is that the operator args is only used during task execution, not DAG parsing.

To solve the issue you described, we'll need to add vars to the RenderConfig:
https://astronomer.github.io/astronomer-cosmos/configuration/render-config.html#render-config

Since you're not blocked (LoadMethod.MANIFEST works), we'll aim to solve this in the 1.3.0 release. Please let us know if you'd like to make this contribution!

@tatiana tatiana added the priority:high High priority issues are blocking or critical issues without a workaround and large impact label Nov 8, 2023
arojasb3 pushed a commit to arojasb3/astronomer-cosmos that referenced this issue Jul 14, 2024
…tronomer#735)

## Description

Currently users have to specify environment variables in both
`RenderConfig` and `operator_args` for the dbt dag so that they're used
during rendering and execution. dbt variables cannot currently be used
in rendering, only during execution in `operator_args`. This PR exposes
`env_vars` and `dbt_vars` in `ProjectConfig` and uses the dbt variables
in dbt ls load mode.

Updates in this PR:

- Deprecates `operator_args` "env" and "var", raising warnings that they
will be removed in Cosmos 2.x
- Deprecates `RenderConfig.env_vars` raising warnings that it will be
removed in Cosmos 2.x
- Adds both `dbt_vars` and `env_vars` within `ProjectConfig`
  - dbt variables are used in dbt ls load method
- Raises an exception if **both** operator_args and ProjectConfig
variables are used.
- Updates docs and example DAGs to use ProjectConfig args.

## Related Issue(s)

Closes astronomer#712 
Closes astronomer#544

## Breaking Change?

None

## Checklist

- [x] I have made corresponding changes to the documentation (if
required)
- [x] I have added tests that prove my fix is effective or that my
feature works

---------

Co-authored-by: Tatiana Al-Chueyr <tatiana.alchueyr@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority:high High priority issues are blocking or critical issues without a workaround and large impact
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants