Hey all - is there an out of the box way to add tags defined in DBT to their representative assets in Dagster? Or I could be barking up the wrong tree here. What I'm trying to test is if I can limit the concurrency of certain DBT models based on a defined tag they might have

hi @Zachary Bluhm! At the moment, there's no analogous concept to dbt tags in software-defined assets, but this is something a few users have mentioned and will likely be implemented at some point in the future. However, I think even if this feature were available, it probably wouldn't solve your underlying issue -- dagster executes all of the dbt assets in a single

dbt run

command, so control over concurrency and order of execution is handled entirely within dbt. So for cases like this, your best bet might be a feature on dbt's end which enabled that sort of concurrency limiting.

hey @owen, thanks for the response! I've create a custom parser for DBT that creates 1:1 ops/assets for each DBT model, which means a

dbt run

will be invoked for each model .In this case would it be possible? Not sure if you can tag ops or not, let me check

ah very cool! but yeah that's correct, at the moment we don't have a way to set concurrency limits for specific op tags. You can set a priority for each op using the

dagster/priority

tag (https://docs.dagster.io/_apidocs/execution#dagster.multi_or_in_process_executor), but that's the extent to which an op tag can impact execution behavior at the moment

Got it! Is there a good place to add this as a feature request? Also - Is there a way to prevent backfills from continuing if a prior job has a failed op?

https://github.com/dagster-io/dagster/issues/8525 we have an issue tracking this here! and we don't have that sort of backfill functionality at the moment, but github issues would be the place for that sort of request

Also - Is there a way to prevent backfills from continuing if a prior job has a failed op?

how we'd like to ultimately support this: https://github.com/dagster-io/dagster/issues/9896 I'm hoping we can get to that before the end of the year in the mean time, I think your best bet would be to include logic inside your op to fast-fail if the prior run / materialization isn't there. we can show you what that would look like if it would be helpful

Hi @sandy! Sorry to dig this old thread up. Would you be able to provide any examples of:

in the mean time, I think your best bet would be to include logic inside your op to fast-fail if the prior run / materialization isn't there. we can show you what that would look like if it would be helpful

Would like to play around with this a bit more as part of our pilot