Solids may be tagged with exception classes on which they should retry.
would be nice to replace this with https://github.com/dagster-io/dagster/issues/2014 at some point
do we want to standardize on using parens in these cases? I don't have a strong opinion but would be nice to be consistent in the codebase
what is behavior exactly of throwing a non retry_on exception? add test?
Sweet, thanks for starting this! My one request here is that it would be nice for retry solids to specify the number of retries and the retry strategy (e.g. retry sequentially vs. exponential backoff vs. uniform sleep)
Generally, I think it's less likely to want to vary the retry behavior with respect specific exceptions, but I'm up for convincing otherwise if you think that's important?
- Requesting changes because I think we need to do some first-principles thinking on what message we want to emit during a retry run and what they mean.
So is relationship here that we are going to emit this message and our step failure message for a failure on celery?
I'm not sure that we should be creating a message with the ERROR setting on a retry. This puts us in a new position where we can have a step emit an ERROR message but still successfully complete.