Custom event source triggers in Function Compute support batch push, configurable event formats, retry policies, fault tolerance, and dead-letter queues. These features control how messages are delivered to your function and what happens when delivery fails.
The features described on this page apply only to custom event source triggers: Simple Message Queue (formerly MNS) queue triggers, RocketMQ triggers, RabbitMQ triggers, Kafka triggers, and DTS triggers.
Invocation methods
Function Compute triggers support two invocation methods. The body size limit determines how many messages can be aggregated in a single request.
| Invocation method | body size limit | Maximum timeout |
|---|---|---|
| Synchronous invocation | 32 MB | 5 minutes |
| Asynchronous invocation | 128 KB | 5 minutes |
Push configuration
Batch push
Batch push aggregates multiple messages into a single function invocation, reducing the number of calls and improving throughput.
After enabling batch push, configure two parameters:
| Parameter | Description | Range |
|---|---|---|
| Batch Push Messages | Maximum number of messages per invocation | 1–10,000 |
| Batch Push Interval | Time interval between invocations, in seconds. Set to 0 for real-time delivery. | 0–15 s |
How batching works
A batch is pushed as soon as any of the following conditions is met — whichever comes first:
The number of accumulated messages reaches Batch Push Messages.
The Batch Push Interval expires.
The accumulated
bodysize reaches the invocation size limit (32 MB for synchronous, 128 KB for asynchronous).
Examples
*Example 1 — interval triggers first:* Set Batch Push Messages to 100 (1 KB each) and Batch Push Interval to 15 s. If 50 messages accumulate within 15 s, the push triggers immediately without waiting for 100 messages.
*Example 2 — message count triggers first:* Same settings. If 100 messages accumulate within 10 s, the push triggers immediately without waiting for 15 s.
*Example 3 — body size limit triggers first (asynchronous invocation):* Set Batch Push Messages to 100 (2 KB each), Batch Push Interval to 15 s, and Invocation Method to Async Invocation. When 100 messages accumulate within 10 s, the total size is 100 × 2 KB = 200 KB, which exceeds the 128 KB asynchronous limit. Function Compute splits the batch automatically: the first batch contains 64 messages and the second batch contains 36 messages.
Push format
Select the format for the event data delivered to your function's entry point.
| Format | Description |
|---|---|
| CloudEvents | Delivers the full CloudEvents envelope, including all metadata fields. Follows the CNCF CloudEvents specification, which standardizes event data across services and platforms. |
| RawData | Delivers only the data field from the CloudEvents envelope, without any metadata. |
The following examples show the event payload for each format, using a Simple Message Queue (formerly MNS) queue trigger with two messages.
CloudEvents
[
{
"id": "c2g71017-6f65-fhcf-a814-a396fc8d****",
"source": "MNS-Function-mnstrigger",
"specversion": "1.0",
"type": "mns:Queue:SendMessage",
"datacontenttype": "application/json; charset=utf-8",
"subject": "acs:mns:cn-hangzhou:164901546557****:queues/zeus",
"time": "2021-04-08T06:28:17.093Z",
"aliyunaccountid": "164901546557****",
"aliyunpublishtime": "2021-10-15T07:06:34.028Z",
"aliyunoriginalaccountid": "164901546557****",
"aliyuneventbusname": "MNS-Function-mnstrigger",
"aliyunregionid": "cn-chengdu",
"aliyunpublishaddr": "42.120.XX.XX",
"data": {
"requestId": "606EA3074344430D4C81****",
"messageId": "C6DB60D1574661357FA227277445****",
"messageBody": "TEST"
}
},
{
"id": "d2g71017-6f65-fhcf-a814-a396fc8d****",
"source": "MNS-Function-mnstrigger",
"specversion": "1.0",
"type": "mns:Queue:SendMessage",
"datacontenttype": "application/json; charset=utf-8",
"subject": "acs:mns:cn-hangzhou:164901546557****:queues/zeus",
"time": "2021-04-08T06:28:17.093Z",
"aliyunaccountid": "164901546557****",
"aliyunpublishtime": "2021-10-15T07:06:34.028Z",
"aliyunoriginalaccountid": "164901546557****",
"aliyuneventbusname": "MNS-Function-mnstrigger",
"aliyunregionid": "cn-chengdu",
"aliyunpublishaddr": "42.120.XX.XX",
"data": {
"requestId": "606EA3074344430D4C81****",
"messageId": "C6DB60D1574661357FA227277445****",
"messageBody": "TEST"
}
}
]RawData
[
{
"requestId": "606EA3074344430D4C81****",
"messageId": "C6DB60D1574661357FA227277445****",
"messageBody": "TEST"
},
{
"requestId": "606EA3074344430D4C81****",
"messageId": "C6DB60D1574661357FA227277445****",
"messageBody": "TEST"
}
]Retry policies
When a request fails, Function Compute retries it according to the configured retry policy. Two policies are available:
| Policy | Retry count | Retry intervals | Total retry duration |
|---|---|---|---|
| Backoff Retry | 3 | Random interval between 10 s and 20 s | — |
| Exponential Decay Retry (default) | 176 | Starts at 1 s, doubles each interval up to 512 s, then holds at 512 s (167 intervals at 512 s) | 24 hours |
When retries are triggered
| Error | Cause | Behavior |
|---|---|---|
| HTTP 429 | Function Compute throttled the request | Retried — throttling is temporary |
| HTTP 5xx | A Function Compute system error prevented the function from running | Retried |
FAQ
Do function logic errors trigger the retry policy?
It depends on the invocation method. For synchronous invocations, logic errors trigger the retry policy. For asynchronous invocations, logic errors do not trigger the trigger-level retry policy — they trigger the separate asynchronous invocation retry policy instead. For details, see Retry Policies.
When a retry is triggered by a function logic error, consider whether retrying will succeed:
If the error is transient, implement retry logic inside the function rather than relying on the trigger-level policy.
If the error is permanent, retries will not succeed and only increase cost. Use the fault tolerance and dead-letter queue settings to handle the failed message instead.
Fault tolerance policies
Fault tolerance controls what happens when a request fails and all retries are exhausted.
| Setting | Behavior |
|---|---|
| Fault Tolerance Allowed | Skip the failed request and continue processing the next one. |
| Fault Tolerance Prohibited | Block the consumption task until the failed request succeeds. |
Dead-letter queue
A dead-letter queue (DLQ) captures messages that cannot be processed after all retries are exhausted. Configure a DLQ only when Fault Tolerance Allowed is enabled.
| DLQ configuration | Behavior |
|---|---|
| Enabled | Unprocessed messages and messages that exceed the retry limit are forwarded to the target service. Supported target services: Simple Message Queue (formerly MNS), ApsaraMQ for RocketMQ, ApsaraMQ for Kafka, and EventBridge. |
| Disabled | Messages that exceed the retry limit are discarded. |
In asynchronous invocation scenarios, if a function encounters an error during execution, the failure record is not delivered to the trigger's dead-letter queue. Instead, it is delivered to the asynchronous invocation destination configured on the Function Compute side. For details, see Result Callbacks.
Concurrent Consumption
Increase throughput by setting the number of concurrent consumption threads. Currently, only Kafka triggers support setting the Concurrent Quota. ApsaraMQ for Kafka concurrent consumption requires coordination with topic partitions. This includes the following scenarios.
Topic partition count = concurrent consumption count: One thread consumes one topic partition.
Topic partition count > concurrent consumption count: Multiple concurrent consumers share all partition consumption.
Topic partition count < concurrent consumption count: One thread consumes one topic partition, and excess consumers are ineffective.
To ensure your resources are fully utilized, choose scenarios where the topic partition count equals the concurrent consumption count or the topic partition count is greater than the concurrent consumption count.