does retryrequested override the op retrypolicy?

No,

RetryRequested

does not override the

RetryPolicy

attached to an op; rather, it provides a way to manually request a retry from within the op's execution logic. According to the documentation, you can use

RetryRequested

to evaluate conditions during execution and decide whether to retry the op. This is useful in nuanced situations where you need to make a decision based on the specific exception or context at runtime. Here's an example from the documentation where

RetryRequested

is used:

python @op def manual():     try:         fails_sometimes()     except Exception as e:         if should_retry(e):             raise RetryRequested(max_retries=1, seconds_to_wait=1) from e         else:             raise

In this example, if

should_retry(e)

returns

True

, a

RetryRequested

exception is raised to request a retry according to the parameters specified (

max_retries=1, seconds_to_wait=1

). If

should_retry(e)

returns

False

, the original exception is raised, and the op will not retry. The

RetryPolicy

attached to an op declaratively specifies how retries should be handled if an exception occurs during op execution. It can be set directly on the op definition or on specific invocations of an op, or at the job level to apply to all ops within the job. If both a

RetryPolicy

and a

RetryRequested

are used within an op, the

RetryRequested

allows for more granular control during execution, but it does not override the

RetryPolicy

. Instead, it works within the constraints of the

RetryPolicy

. For example, if the

RetryPolicy

specifies a maximum number of retries, a

RetryRequested

cannot exceed that number.