Hi team! Could you please explain how to use

RetryRequested

? And how does it work internally? My case: a HTTP request may fail sometimes with different errors that require individual retry policy. E.g. some response means we have to wait 30 seconds and can be retry only once (NotReadyYetException), but another response requires exponential timeout and can be retried more times (TemporaryServerOutageException). Is it possible to model that somehow?

https://docs.dagster.io/concepts/ops-jobs-graphs/op-retries#retryrequested catch your different exceptions and reraise the

RetryRequested

with the different parameters you described

try:
   request
except NotYetReady as e:
   raise RetryRequested(seconds_to_wait=30) from e
except TemporaryOutage as e:
   raise RetryRequested(backoff=Backoff.EXPONENTIAL) from e

@David Hyman RetryRequested does not have "backoff" parameter as I see (dagster 0.15.0). Also I'm not sure what will happen if 2 exceptions are triggered consecutively like this: TemporaryOutage -> NotYetReady

ah you're right, mixed up RetryRequested exception and the RetryPolicy - sorry yes, unclear how (if it is even possible) to switch policies based on outcome, since they're defined on the job level. workaround, depending on how many retries you expect, and how granular view of this you really need... if e.g. it's just to protect from occasional flakiness on network calls, in a short timeframe, I would say keep this one Op running, and handling the retries itself with Tenacity this'll cause less noise and overhead on the executors and run logs etc if the timescales are very short (but of course lose some visibility of the failures - though tenacity has a nice logging feature)