Sensors in branch deployments

[bosmat-elementl]

Can sensors not be activated in branch deployments?

[bosmat-elementl]

No, sensors can only be fully turned on in production deployments. You can navigate to the sensor page and "Test Sensor" will let you run an evaluation tick of the sensor in the branch deployment

[DennisSchwartz]

I have a sensor which creates Dynamic Partition Requests if a new file shows up.

However, since the sensor cannot be turned on in my branch deployment the asset has zero partitions and I cannot test the asset at all in my branch.

Is there any workaround for this?
The 'Test Sensor' function works, but it doesn't actually create the partitions.

[benpankow]

Hi Dennis, I've set up a tracking issue for this issue here: #20272

I listed the ability to use created dynamic partition requests from a sensor, but also a different impl/workaround which might involve being able to manually specify new dynamic partitions in the UI.

For now, I think there is a workaround you can use. The Dagster instance, accessible in op/asset run contexts, has an add_dynamic_partitions method. You could create an op/job you run on your branch that calls this to initialize some sample partitions.

This is also accessible through GraphQL:

mutation {
  addDynamicPartition(
    partitionKey: "my-key",
    partitionsDefName: "my-partitions-def",
    repositorySelector: {
      repositoryName: "__repository__",
      repositoryLocationName: "my-code-location-name",
    }
  ) {
    __typename
    ... on AddDynamicPartitionSuccess {
      partitionsDefName
    }
    ... on PythonError {
      stack
    }
  }
}

[garethbrickman]

Worth noting that the "test sensor" button is currently only available for "regular" sensors and not asset sensors, multi-asset sensors or run status sensors.

You would need to unit test / use direct invocation APIs to test these other sensors for now.

#12346 (comment) shows a good example of testing and mocking asset sensors.

The GraphQL API meanwhile does have a ​sensorDryRun​ mutation that will return a ​DryRunInstigationTick​ with the ​evaluationResult​ that houses info about the runRequest object that would get generated. Example:

mutation SensorDryRun {
  sensorDryRun(
    selectorData: {
      repositoryName: "",
      repositoryLocationName: "",
      sensorName: ""
    },
    cursor: ""
  ) {
    __typename
    ... on DryRunInstigationTick {
      timestamp
      evaluationResult {
        runRequests {
          runKey
          tags {
            key
            value
          }
          runConfigYaml
          assetSelection {
            path
          }
          jobName
        }
      }
    }
    ... on PythonError {
      message
      stack
    }
    ... on SensorNotFoundError {
      message
    }
  }
}

Note that:

• repositoryName = name of the Repository (if none, use "repository")
• repositoryLocationName = name of the Code Location

If the Code location name is something like "foo@bar" then this represents {repository}@{location}