Bit of a weird interaction in using

assets

and

ops

needing contexts . My first op in the asset takes in a context argument and when I click on Materialize on the dagit interface, dagster throws an error saying the op takes a context argument but none was provided. The asset is loaded with the

with_resources()

function, the context in the op needs to access is a resource. The problem goes away if I first define a graph and load the asset with

AssetsDefinition.from_graph()

Hi Vinnie, thanks for reporting this. Would you mind sharing the code snippet so I can reproduce this?

Here’s a minimal implementation. I can send you more info privately, but this already caused it to fail on my end. The resource initializes to a

class

that should contain the

fetch()

method, but the lacking context doesn’t even get us that far so it shouldn’t be much of an issue.

@op(required_resource_keys={"baz"})
def bar(context):
    return context.resources.baz.fetch()

@asset
def foo():
    return bar()

@repository
def repo():
    return [
        *with_resources(
            definitions=[foo],
            resource_defs={"baz": baz},
            resource_config_by_key={"baz": {"config": {"qux": "quux"}}}
        )
    ]

And since I typed it out form memory yesterday, the exact error/stacktrace is the following:

dagster._core.errors.DagsterInvalidInvocationError: Compute function of op 'bar' has context argument, but no context was provided when invoking.
  File "/Users/vinicius/Development/dagster-utils/.venv/lib/python3.9/site-packages/dagster/_core/execution/plan/execute_plan.py", line 224, in dagster_event_sequence_for_step
    for step_event in check.generator(step_events):
  File "/Users/vinicius/Development/dagster-utils/.venv/lib/python3.9/site-packages/dagster/_core/execution/plan/execute_step.py", line 357, in core_dagster_event_sequence_for_step
    for user_event in check.generator(
  File "/Users/vinicius/Development/dagster-utils/.venv/lib/python3.9/site-packages/dagster/_core/execution/plan/execute_step.py", line 69, in _step_output_error_checked_user_event_sequence
    for user_event in user_event_sequence:
  File "/Users/vinicius/Development/dagster-utils/.venv/lib/python3.9/site-packages/dagster/_core/execution/plan/compute.py", line 174, in execute_core_compute
    for step_output in _yield_compute_results(step_context, inputs, compute_fn):
  File "/Users/vinicius/Development/dagster-utils/.venv/lib/python3.9/site-packages/dagster/_core/execution/plan/compute.py", line 142, in _yield_compute_results
    for event in iterate_with_context(
  File "/Users/vinicius/Development/dagster-utils/.venv/lib/python3.9/site-packages/dagster/_utils/__init__.py", line 413, in iterate_with_context
    next_output = next(iterator)
  File "/Users/vinicius/Development/dagster-utils/.venv/lib/python3.9/site-packages/dagster/_core/execution/plan/compute_generator.py", line 73, in _coerce_solid_compute_fn_to_iterator
    result = fn(context, **kwargs) if context_arg_provided else fn(**kwargs)
  File "/Users/vinicius/Development/dagster-utils/dagster_utils/testable_repo.py", line 27, in foo
    return bar(context)
  File "/Users/vinicius/Development/dagster-utils/.venv/lib/python3.9/site-packages/dagster/_core/definitions/solid_definition.py", line 179, in __call__
    raise DagsterInvalidInvocationError(

Thanks Vinnie for sending this over! The reason why this isn't working is because we don't support invoking ops within `@asset`s, though I can add an issue to update our error messaging to fail more gracefully.

Created issue at: https://github.com/dagster-io/dagster/issues/9316

@claire Ah, makes sense. In practical terms this means I’d always have to define graphs and then turn them into assets if I’m chaining ops. Is that right? Explains why I couldn’t find any examples for this in the docs.

Yes, if you have ops that you're using for intermediate computation that you don't want to output as assets, then you should wrap those ops in a graph and then define an asset output via

AssetsDefinition.from_graph

.

Cheers, that’s helpful!