https://dagster.io/ logo
#ask-community
Title
# ask-community
c

Casper Weiss Bang

08/17/2023, 1:30 PM
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)
o

owen

08/17/2023, 10:26 PM
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?
c

Casper Weiss Bang

08/21/2023, 5:05 AM
the last screenshot is the event of asset A, wheras the prior is asset B
o

owen

08/25/2023, 9:01 PM
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)
Opening an issue for this
c

Casper Weiss Bang

08/28/2023, 5:12 AM
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