Marcel Steinbach
03/06/2024, 5:06 PMScout
03/06/2024, 5:06 PMSkipReason
within an asset sensor or by yielding an Output
conditionally within an asset definition. For example, within an asset sensor, you can return a SkipReason
if certain conditions are met, indicating why the asset was not materialized. Here's a snippet from the documentation illustrating this: python @multi_asset_sensor(monitored_assets=[AssetKey("asset_a"), AssetKey("asset_b")], job=my_job) def asset_a_and_b_sensor_with_skip_reason(context): asset_events = context.latest_materialization_records_by_key() if all(asset_events.values()): context.advance_all_cursors() return RunRequest() elif any(asset_events.values()): materialized_asset_key_strs = [ key.to_user_string() for key, value in asset_events.items() if value ] not_materialized_asset_key_strs = [ key.to_user_string() for key, value in asset_events.items() if not value ] return SkipReason( f"Observed materializations for {materialized_asset_key_strs}, " f"but not for {not_materialized_asset_key_strs}" )
In the case of an asset definition, you can use output_required=False
to conditionally yield an Output
only when certain conditions are met. If the conditions are not met, the asset will not materialize, and you can consider it as being "skipped" for that run. Here's an example: python @asset(output_required=False) def my_optional_asset(): if should_materialize(): yield Output(value) # If should_materialize() returns False, no output is yielded, and the asset is not materialized.
Please note that the term "asset op" is not used in the Dagster documentation. Instead, we refer to these as assets or asset definitions. The examples provided are based on the asset-based APIs, which are the preferred approach in Dagster for defining and managing data computations and dependencies.