This topic describes advanced system features for triggers.
Usage Notes
The advanced features described in this topic apply only to custom event source triggers, including 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: synchronous and asynchronous. The limitations for both invocation methods are as follows.
Invocation Mode |
| Maximum Timeout |
Synchronous Invocation | 32 MB | 5 minutes |
Asynchronous Invocation | 128 KB | 5 minutes |
Push Configuration
Batch push requires considering the body size limit to determine whether to reduce the number of aggregated messages. For information about the body size limit, see Invocation Methods.
Batch Push
After enabling batch push, set Batch Push Messages and Batch Push Interval.
Batch Push Messages: The maximum number of messages sent in a single function invocation. A request is sent only when the number of accumulated messages reaches the set value. The value range is [1, 10000].
Batch Push Interval: The time interval for invoking the function. The system aggregates messages and sends them to Function Compute at each interval. The value range is [0, 15], in seconds. 0 seconds means no waiting; delivery is real-time.
Batch push helps you aggregate multiple events in batches. When either the Batch Push Messages or the Batch Push Interval condition is met, the function is triggered, and request messages are pushed in batches to Function Compute.
Batch Push Examples
Example 1
Set the Batch Push Messages to 100 messages, with each message size at 1 KB, and the Batch Push Interval to 15 s. If 100 messages accumulate within 10 s, the push is triggered immediately without waiting for 15 s.
Example 2
Set the Batch Push Messages to 100 messages, with each message size at 1 KB, and the Batch Push Interval to 15 s. If 50 messages accumulate within 15 s, the push is triggered immediately without waiting for 100 messages to accumulate.
Example 3
Set the Batch Push Messages to 100 messages, with each message size at 2 KB, the Batch Push Interval to 15 s, and the Invocation Method to Async Invocation. If 100 messages accumulate within 10 s (total message size 100 × 2 KB = 200 KB), reaching the asynchronous invocation
bodysize limit, the push is triggered immediately. The first batch aggregates 64 messages and pushes them to Function Compute, and the second batch aggregates 36 messages and pushes them to Function Compute.
Push Format
Specify the format for each data element in the Event parameter of the function entry point.
CloudEvents: A specification that describes event data in a universal format, aiming to simplify event declaration and transmission between different services and platforms.
RawData: Delivers only the content of the data field in CloudEvents, without other metadata information in the CloudEvents format.
Take the Simple Message Queue (formerly MNS) queue trigger as an example. The Event format for CloudEvents and RawData types is as follows.
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
Function requests can be retried in some failure scenarios according to the configured retry policies. Retry policy options are as follows.
Backoff Retry: Retries 3 times, with a random interval between 10 s and 20 s for each retry.
Exponential Decay Retry: The default retry policy. Retries 176 times, with the retry interval exponentially increasing to 512 s. The total retry time is 24 hours. The retry intervals are 1 s, 2 s, 4 s, 8 s, 16 s, 32 s, 64 s, 128 s, 256 s, 512 s... 512 s (167 intervals of 512 s in total).
Scenarios for Triggering Retries
429errors: Indicate that Function Compute throttles the request. Throttling is temporary, so it triggers a retry.5xxerrors: Indicate that a Function Compute system exception prevents the function from executing.
FAQ
Q: Will function execution errors caused by function implementation issues trigger the retry policy?
A: For synchronous invocation, function implementation issues trigger the retry policy. For asynchronous invocation, function implementation issues do not trigger the retry policy, but they trigger the asynchronous invocation retry policy. For more information, see Retry Policies.
Function execution error retries include the following two types.
Potentially successful retry
No need to execute a retry policy. Implement the retry within the function.
A retry cannot succeed.
Retries are meaningless and only increase retry costs.
Fault Tolerance Policies
Choose whether to enable fault tolerance when an error occurs.
Fault Tolerance Allowed
If a request fails and retries also fail, skip this request and continue processing the next request.
Fault Tolerance Prohibited
If a request fails and retries also fail, the consumption task blocks.
Dead-Letter Queue
Configure a dead-letter queue only when Fault Tolerance Allowed is enabled.
If you enable the dead-letter queue, messages that are not processed or exceed the retry limit are delivered to the target service. Function Compute supports the following target services: Simple Message Queue (formerly MNS), ApsaraMQ for RocketMQ, ApsaraMQ for Kafka, and EventBridge. Choose different queue types as needed.
If you do not enable the dead-letter queue, messages that exceed the retry limit are discarded.
In asynchronous invocation scenarios, if a function encounters an error, messages are not delivered to the trigger's dead-letter queue. Instead, they are delivered to the asynchronous invocation target service configured on the Function Compute side. For more information, see Result Callbacks.