From e0b807922c147d87498a9086a0657649ce918d0d Mon Sep 17 00:00:00 2001 From: Anton Bendrikov Date: Wed, 11 Dec 2024 09:22:15 +0000 Subject: [PATCH] sensors docs: clarify run_key behavior in a single sensor evaluation --- docs/content/concepts/partitions-schedules-sensors/sensors.mdx | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/content/concepts/partitions-schedules-sensors/sensors.mdx b/docs/content/concepts/partitions-schedules-sensors/sensors.mdx index c3cd252cd84e1..d72ac12a0c018 100644 --- a/docs/content/concepts/partitions-schedules-sensors/sensors.mdx +++ b/docs/content/concepts/partitions-schedules-sensors/sensors.mdx @@ -127,6 +127,8 @@ In the example, a is requested for each file dur Run keys allow you to write sensor evaluation functions that declaratively describe what runs should exist, and helps you avoid the need for more complex logic that manages state. However, when dealing with high-volume external events, some state-tracking optimizations might be necessary. +NOTE: when a sensor evaluation yields multiple objects with the same `run_key`, Dagster will execute all of them. The `run_key` will not be used to deduplicate or skip objects within the same sensor evaluation. + ### Sensor optimizations using cursors When writing a sensor that deals with high-volume events, it might not be feasible to yield a during every sensor evaluation. For example, you may have an `s3` storage bucket that contains thousands of files.