Hey - how does dagster handle the output of dbt

view

tables? I noticed after running such a table that it produces a log like:

op 'test_view_7d9e8' did not fire outputs {'test_view'}

And no assets are actually materialized. Is this expected behavior?

hey @Zachary Bluhm in this example, are you just loading a dbt project with a single model in it with

load_assets_from_dbt_project

or something to that effect? Dagster shouldn't treat models that are materialized as views vs. tables differently as far as I'm aware, so it's possible you're experiencing a bug

In this case its a dbt project with multiple models, the majority of which are incremental and ran fine. Any other details I can provide?

how was the run initiated (i.e. was it part of a job or just from the UI)? and what happens if you try to run just the view model?

It was triggered both manually (through UI) and part of a job that was evoke via sensor The name is changed because we override it - the bug might actually be on our part because we "forked" the dagster_dbt implementation, I just don't remember changing anything related to this (we basically just copy pasted the op implementation)

hm I'd be happy to take a look at the forked code (if you're able to share) but yeah it's hard to think of exactly what could be changed to cause that to happen (seems like it would be hard to do by accident). and I assume that this model is set to be a view just via dbt config right? and this is the only view model? I think the most promising debug route would be to try to execute just the test_view model through the UI, and see what happens, especially focused on what dbt command ends up being executed (i.e. what's under "Running dbt command:..." in the logs). This same information from the failed run would also be useful

Appreciate it 🙏 Going to poke around it a bit more tomorrow, will report back if I hit a rut