A function invocation may fail for various reasons. Different error types and invocation methods (sync or async invocation) affect the retry policy. You can configure a dead letter queue to collect error event information and analyze the causes of failures.
A function invocation may fail for various reasons. Errors can be classified into the following types:
An invocation error occurs before the function is actually executed. It will occur in the following cases:
An execution error occurs during the actual execution of a function. It will occur in the following cases:
It refers to errors of the function platform, such as internal error.
Different error types and invocation methods (sync or async invocation) affect the retry policy.
There are three types of sync invocation: sync invocation by TencentCloud API trigger, API Gateway trigger, and CKafka trigger.
During sync invocation, the error message is returned to the user directly. Therefore, when an error occurs during sync invocation, the platform will not automatically retry. The retry policy (i.e., whether to retry and the number of retries) will be determined by the invoker.
Note:
The CKafka trigger creates a backend module as a consumer, connects to the CKafka instance, and consumes messages. When the backend module obtains a message, a function is invoked synchronously. Since SCF maintains the backend module of the CKafka trigger, it controls the retry policy even in sync invocations.
- For execution errors (including user code execution error and runtime error), the CKafka trigger will perform retry according to your configuration. It retries 10,000 times by default.
- For overrun and system errors, CKafka continuously retries using an exponential backoff algorithm until the invocation is successful.
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 invocations, the retry policies will be as follows:
Dead letter queue (DLQ) is the CMQ of an account. It collects error event information and the causes of failures. If you have configured dead letter queue for your function, events in the following cases will be sent to the dead letter queue:
Note:
The dead letter queue feature is currently in beta test. To try it out, please activate Cloud Message Queue (CMQ).
When the dead letter queue is passed to CMQ, the attribute information and event information will be encapsulated in a JSON request body formatted as follows:
{
"RequestId": "b615b896-d197-47d7-8919-xxx",
"ErrorCode": -1,
"ErrorMessage": "Traceback (most recent call last):\n File \"/var/user/index.py\", line 5, in main_handler\n if 'key1' in event.keys():\nNameError: global name 'event' is not defined",
"Body": {
"AppId": xxx,
"Uin": "xxx",
"SubAccountUin": "xxx",
"RequestSource": "TRIGGER_TIMER",
"FunctionName": "tabortest",
"Namespace": "default",
"Qualifier": "$DEFAULT",
"InvocationType": "RequestResponse",
"ClientContext": "{\"Type\":\"Timer\",\"TriggerName\":\"tabortimer\",\"Time\":\"2020-10-10T01:22:00Z\",\"Message\":\"\"}",
"LogType": "",
"TimeStampForInvoker": "160229310xxx",
"RequestId": "b615b896-d197-47d7-8919-xxx",
"PushTime": "2020-10-10T09:22:00.061824591+08:00",
"RetryNum": 2,
"Ttl": 0
}
}
Note:
Currently, SCF supports a CMQ topic or queue as the dead letter queue. You can select one as needed.
BindingKey
filter when adding a subscriber.Note:
The dead letter queue of a function alias will be subjected to that of the master version. Dead letter queue of the master version refers to the first selected and configured dead letter queue when creating the alias on Console.
Dead letters may fail to be delivered due to permission error, misallocation of resources, and total message size reaching the limit of target queue or topic. You can go to the Monitoring information page on the SCF Console to query the number of dead letter queue delivery errors (DeadLetterErrors
).
Was this page helpful?