Concurrency overrun (ResourceLimitReached) refers to a situation where the number of concurrent executions of an SCF function at the same time exceeds the concurrency quota, leading to a function error. Concurrency overrun is divided into two types: sync invocation and async invocation.
Types of async invocation include async invocation by TencentCloud API trigger, COS trigger, scheduled trigger, CMQ topic trigger, CLS trigger, MPS trigger, etc. For specific trigger invocation types, please see the relevant trigger documentation.
When concurrency overrun occurs in an async invocation, the function will automatically retry. For more information, please see Error Types and Retry Policies.
Types of sync invocation include 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. In this case, the function will return a 432 status code and will not retry the request.
You can view the number of limited times and specific logs of the function in the SCF console.
In async invocation, if your business system is more sensitive to timeliness, you can reduce or minimize the impact of overrun errors on your business system by configuring reserved concurrency. For example, if you want that important messages will not be lost after the set maximum retention time elapses, you should configure a dead letter queue (DLQ).
A DLQ is a CMQ queue under your account used to collect error event information and analyze causes of failures. If you have configured a DLQ for a function, messages in retry failures caused by overrun will be sent to it. For more information, please see Creating Dead Letter Queue.
The reserved concurrency quota is the maximum quota used to guarantee the available concurrency of a function. By configuring the reserved concurrency quota, the function can start enough concurrent instances within the quota, and the maximum number of concurrent instances can reach the configured quota. After the reserved concurrency quota is set, the function no longer shares the concurrency quota at the account level with other functions, which can reduce the possibility of concurrency overrun and guarantee smooth function execution. For more information, please see Reserved Concurrency.