Use asynchronous invocations to more reliably handle time-consuming, resource-intensive, or error-prone requests - Function Compute

When a function contains logic that is time-consuming, resource-intensive, or error-prone, asynchronous invocations let you process requests without blocking the caller. Function Compute immediately returns a response, persists the request in an internal queue, and processes it in the background — even under traffic spikes.

Use cases

Audio and video processing: Encoding, decoding, and transcoding are slow operations. Run them in the background so the frontend stays responsive. Use concurrent async invocations to split large projects into parallel tasks.
ETL pipelines: For extract, transform, and load (ETL) workloads — database queries, file operations, data cleansing — async invocations let independent steps run in parallel and keep large-scale transformations off the critical path.
Web applications: Prevent page freezing when users submit forms, run queries, or load large datasets. Under high concurrency, async invocations distribute request load to prevent service overload.

Trigger an async invocation

Use any of the following methods:

Console: On the Tests tab, select Invoke the function in asynchronous mode.
API: Call InvokeFunction with the x-fc-invocation-type: Async header.

HTTP or custom domain: Set the X-Fc-Invocation-Type: Async request header:

curl -v -H "X-Fc-Invocation-Type: Async" https://example.cn-shenzhen.fcapp.run/$path

Serverless Devs: Set invocation-type to Async. See Invoke a function.
Triggers: Create a trigger that supports async invocations. See Trigger tasks by using events.

Deferred invocations

To delay a function execution after submitting an async request, add the x-fc-async-delay HTTP header to your invocation. Set the value to the desired delay in seconds. Valid values: (0, 3600).

Function Compute invokes the function after the specified delay elapses.

Retry policy

Function Compute automatically retries failed async invocations. The retry behavior depends on the error type.

Default retry behavior

Error type	Retry behavior	Billed
`HandledInvocationError` / `UnhandledInvocationError`	Retried up to 3 times (configurable, range: [0, 8]).	Yes — billed per invocation. See Billing overview.
Concurrency limit exceeded	Retried for up to 5 hours using binary exponential backoff. Initial interval: 0.5 s; subsequent intervals double (1 s, 2 s, 4 s, 8 s, ...).	No
Internal error	Not retried. Join the DingTalk group (ID: 64970014484) for support.	No
Insufficient Function Compute resources	Not retried.	No

By default, each Alibaba Cloud account can run up to 100 instances per region. To increase this quota, visit the Quota Center console.

Configure the retry policy

Set the maximum retry count and message lifetime for a function in the console.

Log on to the Function Compute console. In the left-side navigation pane, click Functions.
Select a region. On the Functions page, click the function you want to configure.
On the Function Details page, go to the Tasks tab. In the Task Mode section, click Modify.
Adjust the parameters in the Task Mode panel, then click Deploy.

Parameter	Description
Task Mode	Enables or disables asynchronous task mode. See Asynchronous tasks.
Maximum Retries	Maximum number of retries for `HandledInvocationError` and `UnhandledInvocationError`. Valid values: [0, 8]. Default: 3.
Maximum Message Lifetime	How long Function Compute retains a request in the queue before discarding it. Applies to all retry types. Valid values: [1, 604800]. Default: 86400. Unit: seconds. The timer starts when the async invocation is triggered. Discarded messages are tracked by the Asynchronous Invocation Trigger Events metric in CloudMonitor. See Monitoring metrics.

Result callbacks

After Function Compute accepts an async request, it persists the request and immediately returns a response. Configure a result callback to handle requests that exhaust all retries, or to notify downstream services after execution.

When configured, Function Compute sends the request context to the specified destination service based on the invocation outcome.

How it works

Supported destination services

Function Compute can route invocation results to the following destination services:

Simple Message Queue (formerly MNS)
Function Compute
EventBridge
ApsaraMQ for RocketMQ

Only ApsaraMQ for RocketMQ 4.x instances are supported as destination services. 5.x instances cannot be configured. See Differences and compatibility between versions 4.x and 5.x.

Configure separate destinations for successful and failed invocations. See Function runtime resource limits for payload limits by destination service.

Event payload

When Function Compute triggers a callback, it sends a JSON payload to the destination. The payload structure differs by destination service.

For Simple Message Queue (formerly MNS), Function Compute, and ApsaraMQ for RocketMQ:

{
  "timestamp": 1660120276975,
  "requestContext": {
    "requestId": "xxx",
    "functionArn": "acs:fc:{regionid}:{accountid}:functions/xxxx",
    "condition": "FunctionResourceExhausted",
    "approximateInvokeCount": 3
  },
  "requestPayload": "",
  "responseContext": {
    "statusCode": 200,
    "functionError": ""
  },
  "responsePayload": ""
}

Field	Description
`timestamp`	Timestamp of the invocation.
`requestContext.requestId`	Request ID of the async invocation.
`requestContext.functionArn`	ARN (Alibaba Cloud Resource Name) of the invoked function.
`requestContext.condition`	Error code of the invocation.
`requestContext.approximateInvokeCount`	Total execution count. A value greater than 1 means the invocation was retried.
`requestPayload`	Original request payload.
`responseContext.statusCode`	System status code. A value other than 200 indicates a system error.
`responseContext.functionError`	Error message from the invocation.
`responsePayload`	Response payload returned by the function.

For EventBridge:

For the EventBridge payload format and field reference, see Event overview. The type field is set to fc:AsyncInvoke:succeeded for successful invocations.

{
    "datacontenttype": "application/json",
    "aliyunaccountid": "143xxxx",
    "data": {
        "requestContext": {
            "condition": "",
            "approximateInvokeCount": 1,
            "requestId": "0fcb7f0c-xxxx",
            "functionArn": "acs:fc:{regionid}:{accountid}:functions/xxxx"
        },
        "requestPayload": "",
        "responsePayload": "",
        "responseContext": {
            "functionError": "",
            "statusCode": 200
        },
        "timestamp": 1660120276975
    },
    "subject": "acs:fc:{regionid}:{accountid}:functions/xxxx",
    "source": "acs:fc",
    "type": "fc:AsyncInvoke:succeeded",
    "aliyunpublishtime": "2021-01-03T09:44:31.233Asia/Shanghai",
    "specversion": "1.0",
    "aliyuneventbusname": "xxxxxxx",
    "id": "ecc4865xxxxxx",
    "time": "2021-01-03T01:44:31Z",
    "aliyunregionid": "cn-shanghai-vpc",
    "aliyunpublishaddr": "199.99.xxx.xxx"
}

Payload limits

Destination service	Payload limit
Simple Message Queue (formerly MNS)	64 KB
Function Compute	See Function runtime resource limits
EventBridge	64 KB
ApsaraMQ for RocketMQ	4 MB

Configure destination services

Log on to the Function Compute console. In the left-side navigation pane, click Functions.
Select a region. On the Functions page, click the function you want to configure.
On the Function Details page, go to the Tasks tab. In the Task Destination section, click Modify.
In the Task Destination panel, configure destinations for successful and failed invocations, then click Deploy.

Destination for successful invocations:

In the Destination for Successful Invocations panel, set Invoke Other Services upon Success to Enable, then configure Destination Service.

Destination service	Required parameters
Function Compute	Function Name, Version or Alias
Simple Message Queue (formerly MNS)	Destination Type (Queue or Topic); Queue name (if Queue) or Topic name (if Topic)
ApsaraMQ for RocketMQ	Instances, Topic
EventBridge	Custom Event Bus

Destination for failed invocations:

In the Destination for Failed Invocations panel, set Invoke Other Services upon Failure to Enable, then configure Destination Service using the same parameters above.

Avoid invocation loops

If Function A sends successful results to Function B, and Function B sends successful results back to Function A, any invocation of Function A starts an infinite loop. Design your destination chains to be acyclic.

Handle callback failures

If Function Compute cannot deliver a callback — for example, due to missing permissions or an unavailable destination — it retries or records the failure based on the HTTP status code returned by the destination.

HTTP status code	Cause	System behavior
5xx	Throttling or content error	Automatic retry in exponential backoff mode. Initial interval: 500 ms; maximum retry duration: 30 minutes.
4xx	Missing permissions, invalid parameter, or payload exceeds the destination's limit	Returns an error and records the error message. No retry.

Monitor callback failures:

To view callback metrics, log on to the Function Compute console. In the left-side navigation pane, choose Advanced Features > Monitoring Metrics, then click the function name.

Metric	Description
`FunctionDestinationErrors`	Number of requests that failed to trigger the destination. Collected per minute or per hour.
`FunctionDestinationSucceed`	Number of requests that successfully triggered the destination. Collected per minute or per hour.

For the full metrics reference, see Monitoring metrics.

What's next

To track the status of each async request through its lifecycle, enable task mode. See Asynchronous tasks.