Clarity on activity error retry state

Hi team,

I was looking through the activity error retry states. Will appreciate some clarity on RETRY_STATE_IN_PROGRESS . When should we expect the state?
IIUC, control only goes to workflow in case, activity processing has terminated.

Regards,
Nitesh

Hi @nitesh237,

You should expect a this activity to occur once the RetryState has been activated due to the code not working properly. The idea is that if workflow code is changed without versioning the workflow progress is blocked without failing workflow. So, if the broken code is rolled back workflow can continue execution without a problem. Failing workflow might be catastrophic. Imagine a few million multi-month workflows failing in production due to a single bad deployment.

Control will automatically go to activity unless, you use a different enumeration such as Abandon, Try_cancel, or Wait_cancellation_completed.

Hi @jreynolds23 sorry for the delayed response here. I have been occupied lately. The statement mentioned above is not clear to me. Will you be able to elaborate on this?

Just to add, RetryState RETRY_STATE_IN_PROGRESS is an internal retry state and is not exposed to the “outside”. Temporal server uses this internally as a retry state to denote activity should be retried.
So,

When should we expect the state?

you should not expect it on client side, it’s internal only.

Thanks @tihomir this helps

Opened [Feature Request] Remove RetryState.RETRY_STATE_IN_PROGRESS from public api · Issue #232 · temporalio/api · GitHub