LEARN. PRACTICE. GROW.Concept and mechanism
The trigger determines how a function is invoked. Input and output bindings connect data to execution but do not remove authorization or failure-handling requirements. A function has one trigger and can have several additional bindings. Retry behavior depends on the trigger and extension; do not transfer configuration from one mechanism to another without confirmation. For supported execution policies, hiding an exception and returning success can prevent expected repetition. Distinguish transient failures from data that will remain invalid on another attempt.
Guided application
For operations with external effects, define a stable identifier and durable state. Document what happens if failure occurs before the effect, after the effect, and before acknowledgment. An early completion marker can lose work; a late uncoordinated marker can permit duplication. A solution can combine a local transaction, reconciliation, and idempotent dependency contracts. In APS, the runbook should explain how to recognize already-completed work before approving a batch replay.
A timer function reads a blob through an SDK. The timer starts execution; the read supplies data and does not constitute a second trigger.
Common pitfalls
Unlimited retries for invalid payloads; memory-only deduplication; log success treated as business success.
Related topics: Data, concurrency, and history · Identity, tokens, and authorization
Define what can repeat and how to demonstrate an already-completed effect.
Reference: Idempotent Functions design · AZ-204 archived objectives 2026-01-14; retired 2026-07-31