How Serverless Function Compute Guarantees Exactly‑Once Task Execution

Introduction

Task systems in big‑data and messaging domains require reliable deduplication to ensure accurate execution, especially in high‑precision scenarios such as finance. Serverless Task, a serverless task‑processing platform, offers exactly‑once semantics to guarantee that each task is triggered only once, both from the user’s perspective and within the system.

Message Delivery Semantics

At‑Most‑Once: a message is delivered at most once, but may be lost during network partitions or component failures.

At‑Least‑Once: a message is delivered at least once; retries ensure delivery but can cause duplicate processing.

Exactly‑Once: a message is delivered exactly once; in practice this relies on retry mechanisms combined with idempotent processing on the receiver side.

Serverless Function Compute Exactly‑Once Capability

The function compute service provides task distribution with exactly‑once semantics, treating repeated triggers of the same task as a single execution.

System‑Side Guarantees

The scheduler’s failover must not cause multiple executions of step 3.2 (the actual worker run) even if intermediate components fail.

Users can retry step 1 (task submission) without causing additional executions of step 3.2.

The underlying message queue (RocketMQ) stores three replicas and offers unique consumption semantics. Each message becomes invisible to other consumers after being fetched, and the consumer must periodically extend the invisibility timeout until processing completes, after which the message is explicitly deleted.

Scheduler Failover Handling

If a scheduler crashes before a message reaches the worker, another scheduler will re‑fetch the message after the invisibility period expires, ensuring the task is still triggered. If the worker has already started processing, the worker’s agent detects the duplicate request and ignores it, reporting the result back to the new scheduler.

User‑Side Deduplication with TaskID

To handle client‑side retries (e.g., after a timeout), the platform introduces a globally unique TaskID (StatefulAsyncInvocationID). When a task with an existing TaskID is submitted, the service rejects it with a 400 error, allowing the client to know the task was already accepted.

import fc "github.com/aliyun/fc-go-sdk"

func SubmitJob() {
    invokeInput := fc.NewInvokeFunctionInput("ServiceName", "FunctionName")
    invokeInput = invokeInput.WithAsyncInvocation().WithStatefulAsyncInvocationID("TaskUUID")
    invokeOutput, err := fcClient.InvokeFunction(invokeInput)
    // handle output and error
}

This Go SDK snippet shows how to submit a task with a unique TaskID, ensuring exactly‑once execution even under repeated retries.

Conclusion

The Serverless Task system’s architecture—combining a reliable multi‑replica message queue, scheduler failover logic, and user‑provided TaskID—delivers exactly‑once task triggering suitable for scenarios demanding strict execution accuracy.