Hi team! I’m trying to use context.solid.name to get a unique name for every op run within a run. For example, if I have one op that I’m calling twice within the same run, I want to get the unique string identifying a specific op run. (dagster usually appends a number, like op_2). 1. Am I right to assume context.solid.name is unique within a run? There won’t be any clashes? 2. I’m getting an error if I try to access “solid” from a context built using build_op_context. Whats the best way to do this?

E       dagster.core.errors.DagsterInvalidPropertyError: The solid property is not set on the context when a solid is directly invoked.

Hi Andy. To answer your question in part, yes, the name of an op is unique across a run (and across a repository). The uniqueness of an op name is what allows Dagster to distinguish between ops that are invoked in many places within a repository that are defined the same otherwise.

Yes sorry that makes sense

Ok sweet. Sorry I've never seen this pattern before. Could you give me a little more code maybe?

To answer your question above, yes, in a call to

context.solid.name

dagster will return the aliased name of the op ("op_a_1").

hm i havent tried, but I’m sure we could

Well, dagster will only apply aliasing ("op_a" being called twice -> "op_a_2") in a job invocation. So an op invoked with context from

build_op_context

will simply have the name that it is defined with.

Wait sorry, In the unit test, I don't need op_2, that's fine that it doesn't append the number. But it doesn't even give me the op name in the unit test, it fails.

Try writing

<http://context.log.info|context.log.info>(context.solid_def.name

instead of

context.solid.name

wait sorry @claire I need the number when the pipeline is actually running. so when I run the pipeline, I need “op_a_2”. but in tests, I’d be happy with “op_2"

Yes, that's correct. solid_def.name would return

op_2

. I think if you want to test, you could try writing unit tests that run the job through

my_job.execute_in_process()

and then you'll be able to access the aliased name (

op_a_2

).

thats not what i’m seeing

ah, to clarify, I mean that

solid_def.name

will always return

op_a

. But if you run the job an op that contains

context.solid.name

you'll get the aliased name

yeah that doenst work, I need the aliased thing

Why not test via

execute_in_process

? Then you'll be able to access the aliased name

because i’m testing specific ops

You can provide an op selection via

my_job.execute_in_process(op_selection=["my_op"])

I think there’s also another problem I’m seeing where if you have two different graphs using the same op, the name thing doesnt evenwork so lets say you have graph1 that calls op_a, and graph2 that calls op_a. In the ui, it shows up as “graph1.op_a” as the name. but context.solid.name just gives us “op_a”, but I want “graph1.op_a”. Is that how you understand it works?

Yep, that makes sense. One way around that is you could attach a job identifier (either the job name or the run id) to the log:

@op
def my_test_op(context):
    <http://context.log.info|context.log.info>(f'{context.solid.name}.{context.run_id}')

Unfortunately that still doesn't solve the testability problem where

context.solid.name

is not available in the test context. We do have an issue tracking this though: https://github.com/dagster-io/dagster/issues/6493

i see

Got it. Instead, you could use the step key from the step execution context:

@op
def my_op(context):
    print(context.run_id + "." + context.get_step_execution_context().step.key)

which will get you the key within a graph (e.g.

<http://my_graph.my|my_graph.my>_op

).

got it, interesting, ill take a look!