Heya, is there a way to prevent auto-materialization from launching new runs if there's already a materialization job running for that particular asset? We're experiencing an issue when we have assets A and B where B depends on A and they've got a freshness policy (with a cron schedule?). If both A and B are due at 30 minutes past the hour with 15 minute lag, Dagster schedules a single run for both assets at 15 minutes past the hour, but then when A is done materializing (i.e. the "asset materializated" event is emitted while the overall run is still ongoing), the auto-materializer schedules more runs for asset B since the upstream data is more fresh. For further context, we're dealing with dbt assets and so within the run that materializes both asset A and B, dbt will take care of their interdependency and thus no extra run for B will be required.

hey @Marvin Rösch! how long does A take to execute? and does B have any source-asset dependencies (or in dbt language, does it depend on any dbt sources)? I ask as freshness based scheduling is intended to take in progress runs into account, but the latest release (coming out today) patches an issue that was interfering with that

The affected assets do indeed have source assets as parents as well, @owen. I'll try out the new release today and report back if that fixes our issue. I had been trying to replicate the issue and wasn't able to, but I also hadn't included source assets in my repro attempt 😅 A takes up to 5 minutes to execute. The additional runs for B would trigger as soon as the materialization for A was done.

glad it's working!