how do I mark run status SKIPPED from an op with p...
# ask-ai
d
how do I mark run status SKIPPED from an op with python
s
In Dagster, the concept of marking a run as "skipped" from within an op is not directly supported as per the documentation. Ops in Dagster are the fundamental units of computation, and when an op is executed, it either succeeds, fails, or is skipped due to unmet dependencies or upstream failures. However, an op itself does not have the capability to mark the entire run as skipped. If an op has unmet dependencies, such as missing inputs from upstream ops that did not execute or failed, Dagster will automatically skip the op and note this in the run logs. This behavior is mentioned in the documentation regarding the log message for skipped ops due to dependencies. If you want to conditionally skip an op based on some logic within the op, you can use the
Output
object with the
is_required
parameter set to
False
. This allows you to yield an
Output
conditionally, effectively skipping the op's main action without causing a failure. Here's an example from the documentation:
Copy code
python from dagster import op, Out, Output  @op(out=Out(is_required=False)) def conditional_op(context):     if should_skip():         <http://context.log.info|context.log.info>("Skipping op execution")         return     # Otherwise, perform the op's action     yield Output(result)
In this example,
should_skip()
is a placeholder for your custom logic that determines whether to skip the op's action. If the condition is met, the op logs a message and returns without yielding an
Output
, effectively skipping its action. If you want to skip the execution of an entire job or a set of ops, you would typically use a sensor or schedule with a
SkipReason
. Sensors and schedules can return a
SkipReason
to indicate why no runs were requested. This is not the same as marking a run as skipped, but it is a way to programmatically prevent runs from being initiated. For more complex scenarios, such as handling run failures or cancellations, you might need to implement custom logic within your ops or use hooks and sensors to respond to run status changes. If you need to mark a run as skipped after it has started, which is not a typical use case in Dagster, you would likely need to handle this outside of the standard op execution flow, potentially by interacting with the Dagster instance's run storage to update the run's status, which is not a documented or recommended approach.