We got a weird bug this morning Dagster used to have a

Skip condition if [...] a run is already running

or something. It isn't there now (Version 1.4.3). We have a job that runs every morning, i.e

A -> B -> C

. B has an automaterialization policy. Well when the job finished A, but before B started, the policy kicked in, started to materialize asset B. well when the pipeline then continued we had a concurrency issue, the job (due to B) failed, which meant that C never got materialized. I assume this is a bug? shouldn't the auto materialization policy back off if the asset is already in an active run? It's a non partitioned asset (B)

Hi @Casper Weiss Bang -- this is definitely not intended. Internally, a "Parent updated" reason should not fire for asset B if that new parent materialization is part of an in-progress run that will materialize B. Do you have a screenshot of the automaterialize history tab for B, and the materialization events for A during that time period?

the last screenshot is the event of asset A, wheras the prior is asset B

Ah sorry, missed the ping on this! I think I see what's going on here (it has to do with the fact that your job is manually launched, and contains both partitioned and non-partitioned assets)

it has to do with the fact that your job is manually launched

Might be because we are not on the latest version, and the auto materialization assets are registered as manual 🙂 i'll update. Thanks for tracking it though! awesome work