Averell
08/26/2022, 9:32 AMsandy
08/26/2022, 2:55 PMjohann
08/26/2022, 5:56 PMavoid having multiple instances of the same job for the same partition running in parallelI haven’t thought about this use case, but yeah it should be possible using the run queue. We tag partition runs with
dagster/partition:<name>
, and the run queue has a nifty applyLimitPerUniqueValue
optionjohann
08/26/2022, 5:59 PM# dagster.yaml
run_coordinator:
module: dagster.core.run_coordinator
class: QueuedRunCoordinator
config:
tag_concurrency_limits:
- key: "dagster/partition"
value:
applyLimitPerUniqueValue: true
limit: 1
should work. Note that this will restrict all runs on the instance with matching partition keys, including runs of different Jobs (if the partition sets had overlapping keys). It’s not currently possible to add an AND to the limit to filter it down to just the one parition setjohann
08/26/2022, 6:00 PMeven better, avoid having multiple instances of the op that materializes the same asset partitionop level concurrency limits are something we’ve prototyped a bunch but don’t currently support
Averell
08/29/2022, 9:48 AMdagster/partition:<name>
when enqueueing jobs? Or it's added by Dagster by default?sandy
08/29/2022, 2:39 PMAverell
08/29/2022, 10:19 PMAverell
08/30/2022, 8:18 AMdagster/partition
prevented me from materialising the same partition (e.g: 2022-08-30) for those two assets at the same time. I guess the uniqueness is checked on the partition_key only, not the asset_key.johann
08/30/2022, 1:49 PMAverell
08/31/2022, 3:08 AM