👋 dagster team! Auto-materialization question... We have a lot of assets that depend on multiple upstream assets. We often see strange behavior when upstream assets update close to each other. For example: asset C depends on A and B. When A updates, the automaterializer kicks of a run for C but while it does that (or shortly before) B gets materialized. The materialization history for C shows asset B as "Will Update", and kicks off a run. When asset C and B eventually materialize, C is out of date again but C doesn't re-materialize to include changes from B, leading to missing data in C. Asset C detects it has upstream changes but no run is kicked off by the auto-materializer. Anything we can do to remedy this odd behavior? Thanks for the help 🙏

@owen Could you take a look at this question when you get online?

It looks like each asset (C & B) is included in a different concurrent dbt run. They are updating at the same time essentially but in a different dbt run, making it so dbt can't determine to correct execution order. The first concurrent run seems to only include assets that depend on a frequently updated observable source?

Hi @Henri Blancke! I'm looking into this, and it's definitely odd behavior. I believe you're correct that the fact that it's separating out the dbt executions into separate pieces is at play here, and I'm currently investigating why that might be happening

Thanks!

Alright, I believe this is related to: https://github.com/dagster-io/dagster/issues/13437, which we initially attempted a fix for, but ended up being unreliable, and so was reverted. In your graph, do you have any cases where you have a single call to load_assets_from..., which contains some dbt models which are upstream of some non-dbt asset, and other models which are downstream of that asset?

@owen yes in this particular case we have a dbt asset that's upstream from 2 non-dbt assets.