This message was deleted.

that error looks like the op/asset is yielding an output named

sixth_dbt

, but the only output available is

third_dbt

.

but what does this mean? these dependencies have always worked and are really, really simple

do you do any explicit naming of assets?

Yes, for example:

dbt_assets_1 = load_assets_from_dbt_project(project_dir=DBT_PROJECT_DIR, select="first_dbt")
dbt_assets_2 = load_assets_from_dbt_project(project_dir=DBT_PROJECT_DIR, select="second_dbt")
dbt_assets_3 = load_assets_from_dbt_project(project_dir=DBT_PROJECT_DIR, select="third_dbt")

ah, i see. where is

sixth_dbt

coming from?

sixth_dbt, comes from second_dbt here is the code:

/*{{ config(materialized='view') }}*/

{{ config(
    tags='advertisement'
) }}

select *
from {{ ref("second_dbt") }}

gotcha, so these are models in the dbt project. so your

dbt_run_project

job is materializing all the indvidual assets in the dbt project. and that specific op is yielding an asset key that doesn't exist (or something). My first thought is that maybe

sixth_dbt

is not able to run correctly in the dbt project? Does the model run okay?

If I run

dbt run

, everything works perfectly in a few seconds. :(

yeah, i think what might be happening is that when you load the assets multiple times, duplicate entries get created for assets that are named the same thing. if you just did

dbt_assets = load_assets_from_dbt_project(project_dir=DBT_PROJECT_DIR)

once, without a

select

, i wonder if that would work.

It's frustrating because this same project was running smoothly until few weeks ago, I just cloned my own code without changing anything

great time to deprecate a dbt model 😉

I am going to try this solution, maybe you just lit up the light bulb in my brain ahahaha

woo! i think the "restart from failure" problem is endemic to the limitations of dbt / the integration. dagster would need to be smart enough to run

dbt run --select failed_model+

dynamically to accommodate it. One thing you might be able to do instead is to go to Global Asset Graph > select

failed_models+

in the selector, then run a new job

Later I am going to try this! You are so kind, thank you! 🤩🙏🏻

cc @owen regarding restart from failure w/ dbt assets

ah that's a good point about restart from failure -- right now the button in the UI purely restarts from the failed ops, but because all of the dbt models run in the same operation (dbt run), this results in the behavior you're experiencing. One thing we're considering adding to the job / global asset graph pages is a "rematerialize failed assets" button (naming tbd), which would streamline the process that @Stephen Bailey’s describing (because you wouldn't need to manually come up with that asset selection). As it stands now though, that's what I'd recommend doing 🙂

Thank you @owen, @yuhan and again @Stephen Bailey. I am looking forward to this function. It would be absolutely perfect for my company!

hi @Lorenzo! It's not quite a "restart from failure" button, but there is now a "rematerialize stale assets" button in the UI, which should work for this use case -- essentially, assets whose parents have been materialized more recently than they have been are marked as stale, and you can run just those stale assets from the UI. If a dbt run fails halfway though, then the assets that did not get materialized will all be "stale" (as their parents were rematerialized, but they weren't), so this should, in most cases, be the selection you want.