Get failed asset from dagster run with @run_status_sensor/@run_failure_sensor #24529
-
|
I want to come up with a As you can see in the middle asset there's an intentional error. If I run these assets in one run then Is there a way to find out from the run which exact asset failed. Why I want to do this? Lets say that every asset is in a different code location or in a different group like in the example. And every group/code location has an owner. If a run fails then I want to send a slack alert only to the asset's owner which means I need to figure out from the run which asset failed. Right now haven't figured out a way to do that. I can see the run that failed but I wouldn't want to send an alert to all of the owners of those assets. Only to the owner of the asset that actually failed. So in this case I would like to a slack alert only to engineering group. @asset(group='finance')
def upstream() -> None:
return
@asset(deps=[upstream],
group='engineering')
def middle() -> None:
wow
return
@asset(deps=[middle],
group='infra')
def downstream() -> None:
return |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
There is a workaround (or this) but that solves only half the problem. Based on that example I was able to get asset naming from |
Beta Was this translation helpful? Give feedback.
-
|
At the moment, there is unfortunately no general way to detect the specific asset within a multi-asset that caused the failure (as with |
Beta Was this translation helpful? Give feedback.
-
|
Can this be remediated now with the dbt translators and owners set there and asset based alerts (though tese are not OSS)? |
Beta Was this translation helpful? Give feedback.
At the moment, there is unfortunately no general way to detect the specific asset within a multi-asset that caused the failure (as with
@dbt_assets). When the step fails, that simply marks all assets that did not get materialized as failed. No information about the specific dbt model that caused the failure is extracted from the command. For dbt specifically, the best option here would likely involve manually emitting some sort of specific log (e.g. an AssetObservation) during that step in the case of failure that would let you detect the specific dbt key that caused the failure.