Is it possible to access dagster context within an asset_check?

Yes, it is possible to access the Dagster context within an

asset_check

. When you define an

asset_check

, you can access the context by including it as a parameter in your check function. The context provides various runtime information and functionality, such as logging and accessing resources. Here's an example from the documentation that illustrates how to define an

asset_check

that uses the context:

python
from dagster import asset, asset_check, AssetCheckResult

@asset
def my_asset():
    # Asset computation logic
    ...

@asset_check(asset=my_asset)
def my_asset_check(context):
    # You can use the context here for logging, accessing resources, etc.
    <http://context.log.info|context.log.info>("Running asset check.")
    # Check logic
    return AssetCheckResult(passed=True)

In this example, the

my_asset_check

function is an

asset_check

associated with the

my_asset

asset. The

context

parameter is used within the check function to perform logging. You can similarly use the context to access other runtime information and functionalities as needed. How to get the code location of a given ... button get code versions for a set of assets be... button Allow accessing the asset value loader f... button How to: access the DagsterInstance button Thank you for your feedback!

Can I get the job_id via the context object?

As of my knowledge cutoff date in early 2023, the context object within an

asset_check

does not directly provide a

job_id

. The

job_id

is typically associated with a specific run of a job, and

asset_check

functions are meant to validate assets rather than being tied to a specific job execution. However, if you are within the context of a running job (for example, within an op or a hook), you can access the

run_id

of the current job execution through the context object. The

run_id

is a unique identifier for each run of a job. Here's how you can access it:

python @op def my_op(context):     run_id = context.run_id     <http://context.log.info|context.log.info>(f"The run ID for this job is: {run_id}")

In the above example,

context.run_id

retrieves the

run_id

for the current job execution within an op. If you need to access the

job_id

or other similar metadata from within an

asset_check

, you would typically need to pass that information to the check function through some other means, such as by including it in the asset's materialization metadata or by using resources that can provide such information. If there have been updates to Dagster after my knowledge cutoff date that allow for accessing

job_id

directly within an

asset_check

context, I would recommend checking the latest Dagster documentation or release notes for the most up-to-date information.

@Scout could I get the job name from the context object?

As of my knowledge cutoff date in early 2023, within the context of an

asset_check

, you do not have direct access to the job name because asset checks are designed to be independent of specific job runs. They are meant to validate the integrity of an asset rather than being tied to the execution context of a job. However, if you are within the context of a running job, such as within an op, you can access the job name through the context object. Here's an example of how you might access the job name within an op:

python @op def my_op(context):     job_name = context.job_name     <http://context.log.info|context.log.info>(f"The job name is: {job_name}")

In this example,

context.job_name

would give you the name of the job that the op is a part of. For

asset_check

, since it is not directly associated with the execution of a job, the job name is not inherently part of the context. If you need to use the job name within an

asset_check

, you would have to pass it explicitly, perhaps as a resource or through some other mechanism that makes it available to your asset check function. Please check the latest Dagster documentation for any updates or changes to this behavior that may have occurred after my knowledge cutoff date.