Automatic Error Handling

Overview

Copy link to clipboard

If a process encounters a problem within a given activity, the process flow halts at the activity. One of two things occur.

1. If it encounters a safeToRetry exception, it is automatically retried.
   • If the error was transient, the activity completes and process flow resumes.
   • If the error is not resolved after the maximum number of retries, the activity becomes canceled by exception.
2. If it encounters an Activity Execution Exception it becomes canceled by exception.

See also: Process Errors

Automatic Retries

Copy link to clipboard

A number of internal and external operations provide error-handling retries to respond automatically should your application or network experience minor disruptions due to time-out errors, such as a very heavy transaction load.

The transaction is only retried when no data has been updated or changed.

Internal Error Handling

Copy link to clipboard

• If Appian smart services, Scripting functions, People functions, or xpath*() functions suffer an internal time-out error with a transaction that can be safely retried, the transaction is retried automatically.
• Write transactions executed by the Write to Data Store Entity Smart Service and Write to Multiple Data Store Entities Smart Service will be automatically retried if the write fails due to the data being locked by the database.

See also: Process Nodes and Smart Services and Appian Functions

External Error Handling

Copy link to clipboard

• If the Call Web Service Smart Service encounters an unavailable web service or a request timeout (503 or 408 error), the activity is automatically retried.
• If the Send E-Mail Smart Service encounters a connection error when trying to send the email, the activity is automatically retried.
• Transitory errors for the Query Database Smart Service are not retried.

Retry Intervals

Copy link to clipboard

Should an error occur, automatic retries occur at approximately the following intervals after each subsequent error. The interval between retries roughly doubles after each attempt.

• 32 seconds
• 64 seconds
• 127 seconds
• 4.5 minutes
• 9 minutes
• 17 minutes
• 34 minutes
• 67 minutes
• 135 minutes
• 4 hours and 30 minutes
• 9 hours
• 18 hours

If the retry that occurs after the last interval fails, no additional retries occur.

It is not possible to predict exactly when a subsequent retry occurs, due to the variable time spent retrying and catching each new error.

Logging

Copy link to clipboard

Retries are logged at the Debug level in the engine server logs.

Final retries are logged as errors.

See also: Application Engine and Gateway Logging

Feedback

Copy link to clipboard