Second question is about testing for errors. Let’s assume i have a simple solid that is supposed to fail for a certain input. I use this input in the test and want to test if the correct error is raised (in this case

TypeError

). However, since dagster catches that error and turns it into another type of error, I have to do something like this:

import unittest

from dagster import DagsterExecutionStepExecutionError, execute_solid, lambda_solid

@lambda_solid
def add_one(x):
    return x + 1
 
class AddOneTest(unittest.TestCase):
    def test_fail_for_string(self):
        with self.assertRaises(DagsterExecutionStepExecutionError):
            execute_solid(add_one, input_values={"x": "s"})

Any good ideas on how I can test for the underlying

TypeError

instead of the dagster error easily?

There is a

raise_on_error

flag that we dont expose on

execute_solid

that we probably should. It is available on

execute_pipeline

so you could try it there by manually wrapping your solid to test in a pipeline and verify if that approach works.

we could also write a test assertion helper that unwraps the wrapped error

I just manually wrapped the solid into a pipeline and used

execute_pipeline

. Then I can set

raise_on_error = False

and get the return value from

execute_pipeline

without failing. I think that is what you meant? The easiest way to get to the

TypeError

I want, when

res

is the

PipelineExecutionResult

I got: Finding the last event with

event_type_value='STEP_FAILURE'

, in this case the third from last, then calling

res.event_list[-3].step_failure_data.error.clas_name

. I am happy that there is a way to get this, but maybe a helper for getting to this more easily like max said would help.

Ya we will definitely add somethings to make it easier - just wanted to help you get unblocked. I also really appreciate that you took the time to lay out what you ended up doing with such detail.

Thank you!

Fix is out in 0.6.4