Working with Retry Count in Scripts
4 min
retryable workflow steps in activate are created using job workflow\ callretryable( ) when a step is configured this way, the platform automatically tracks retry state as part of the job execution this includes how many times the step has been retried and whether the current attempt is the final one this retry metadata is exposed to scripts through the evaluator, allowing you to adjust behaviour dynamically based on the current retry context accessing retry information bool lastretry = job evaluator getboolean(srv, "=//retrylast", false); int retrynumber = job evaluator getinteger(null, "=//retrytimes", 1); retrylast indicates whether the current execution is the final retry attempt retrytimes returns the current retry count (starting from 0 or 1 depending on configuration and context) both methods include a fallback value to ensure the script continues safely if the retry context is not present how it works when a retryable step is executed the workflow engine records retry configuration (such as max retries and delay) each time the step is retried, the retry counter is incremented the evaluator exposes this state via the =//retrytimes and =//retrylast expressions scripts can read these values at runtime and alter behaviour accordingly this allows for more controlled and intelligent retry handling compared to static retry logic example usage public jobworkflow\ result internalwait(serviceinstance srv) { bool lastretry = job evaluator getboolean(srv, "=//retrylast", false); int retrynumber = job evaluator getinteger(null, "=//retrytimes", 1); // apply different logic on a specific retry attempt if (retrynumber == 2) { job logaudit("retry logic", "executing second retry behaviour "); } // handle final retry differently if (lastretry) { job logerror("retry failed", "final retry reached escalating "); return jobworkflow\ result nextstep; } return jobworkflow\ result retry; } common use cases escalating logging or alerting on the final retry introducing alternative logic after a certain number of failures adding delays or additional checks on later retries preventing repeated execution of expensive operations using retry metadata in this way helps make workflows more resilient and reduces unnecessary failures or repeated actions