The

build_output_context

function incorrectly has the arguments

step_key

and

name

labeled as optional. The output context can be created, but when something internally tries to access those properties and finds a

None

value, it errors: https://github.com/dagster-io/dagster/blob/master/python_modules/dagster/dagster/_core/execution/context/output.py#L796 https://github.com/dagster-io/dagster/blob/master/python_modules/dagster/dagster/_core/execution/context/output.py#L188

ah interesting -- by "something internally tries to access those properties", do you mean that some dagster framework code is trying to access the

step_key

? if so, do you happen to have a stack trace handy?

Correct. I found it while writing tests for a custom IO manager. Don't have a stack trace at hand now but I'll reconstruct it tomorrow and send it over. The gist of the implementation was:

def my_test():
    ...
    out_context = build_output_context(asset_key=out.dest_asset)
    in_context = build_input_context(
        upstream_output=out_context,
        asset_key=AssetKey(out.dest_asset),
        dagster_type=DagsterType(
            type_check_fn=lambda _, x: True,
            name="mock_io_dagster_type_test",
        ),
    )
    [i for i in manager.handle_output(out_context, out)]
    assert manager.load_input(in_context).dest_asset == out.dest_asset

gotcha -- that stack trace would be great 🙏

@owen happy to announce that it was user error. I tried reconstructing it just now but couldn’t manage, the test runs through without raising any errors even with just the

asset_key

parameter now. I probably had something else misconfigured. Though this made me realize that

build_output_context

accepts a

str

as the

asset_key

, while

build_input_context

only accepts an

AssetKey

instance.

ah great good to know -- and that build_input_context thing should be a quick fix