A function invocation may fail for various reasons. Different error types and invocation methods (sync or async invocation) all affect the retry policy. You can configure a dead letter queue to collect error event information and analyze causes of failures.

Error Type

A function invocation may fail for various reasons. The errors can be divided into the following types:

Invocation error

An invocation error occurs before the function is actually executed. It will occur in the following cases:

• Invocation request error. For example, the data structure of the event passed in is too large, an input parameter does not meet the requirements, or the function does not exist.
• Invoker error. This error generally occurs when the invoker has no sufficient permissions.
• Overrun error. The number of concurrent invocations exceeds the maximum concurrency.

Execution error

An execution error occurs during the actual execution of a function. It will occur in the following cases:

• User code execution error. This type of errors occurs during the execution of user code; for example, the function code throws an exception, or the format of the returned result is exceptional.
• Runtime error. During function execution, the runtime is responsible for pulling and executing user code. A runtime error refers to errors detected and reported by the runtime, such as function execution timeout (for the timeout period, please see Quota Limits) and code syntax error.

System error

It refers to errors of the function platform, such as internal error.

Retry Policy

Different error types and invocation methods (sync or async invocation) all affect the retry policy.

Sync invocation

There are three types of sync invocation: sync invocation by TencentCloud API trigger, API Gateway trigger, and CKafka trigger.
In sync invocation, the error message will be directly returned; therefore, when an error occurs in sync invocation, the platform will not automatically retry, and the retry policy (i.e., whether to retry and the number of retries) will be determined by the invoker.

Note：

A CKafka trigger will create a backend module as a consumer that can connect to a CKafka instance and consume messages. After obtaining the message, the backend module will synchronously invoke the triggered function. Since the backend module of the CKafka trigger is maintained by SCF, the retry policy for sync invocation will also be controlled by SCF:

• For execution errors (including user code errors and runtime errors), the CKafka trigger will retry according to the configured retry times, which is 10,000 by default.
• For overrun errors and system errors, the CKafka trigger will continue to retry in an exponential backoff manner until it succeeds.

Async invocation

There are four types of async invocation: async invocation by TencentCloud API trigger, COS trigger, timer trigger, and CMQ topic trigger.
When the following types of errors occur in async invocation, the retry policies will be as follows:

• Execution error (user code execution error or runtime error): when an error of this type occurs, the SCF platform will automatically retry twice, where the first retry will occur 1 minute after the original event and the second one 2 minutes after the first one. While automatically retrying, the function can still handle new trigger events normally. If a dead letter queue is configured, events with three consecutive failures will be passed to the queue; otherwise, the events will be discarded by the SCF platform.
• Overrun error and system error: when an error of this type occurs, the SCF platform will retry for 24 hours, and the retry interval will increase to 1 hour by exponential backoff. If a dead letter queue is configured, events that still fail after 24 hours of retries will be sent to the dead letter queue for further processing on your own; otherwise, they will be discarded by the SCF platform.
• Invocation request error and invoker error: when an error of this type occurs, the SCF platform will not retry, because events that fail due to this type of errors will not succeed even after retries.

Dead Letter Queue

A dead letter queue is a CMQ queue under your account that is used to collect error event information and analyze causes of failures. If you have configured a dead letter queue for a function, an event will be sent to the dead letter queue if:
It still fails after the SCF platform retries it twice due to a user code execution error
It still fails after the SCF platform retries it for more than 24 hours due to an overrun error or system error
*Message retention in the async queue reaches the upper limit.

Note：

The dead letter queue feature is currently in beta test. If you want to try it out, please apply for activation of CMQ.

Dead letter queue message attributes

• RequestID: unique event ID
• ErrorCode: event error code
• ErrorMessage: error message

Dead letter queue creation process

Note：

SCF currently supports a CMQ topic or queue as the dead letter queue for your choice.

1. Log in to the CMQ Console and create a dead letter queue.
   CMQ topics support filtering by tag or route match. To ensure that your subscribers can receive all error messages, when adding a subscriber, please leave the tag filter empty and enter "#" for the BindingKey filter.
2. Log in to the SCF Console and create a function.
   The executing role of the function must have access permission to the CMQ topic and queue, which has already been configured for the default executing role in SCF. If you use a custom role, be sure to grant it such permission.
3. Configure the dead letter queue.
   You can configure the dead letter queue on the "Create Function" or "Configure Function" page.