Event Grid delivers the same blob-upload event twice to the city’s summarizer Function. How should the Function stay idempotent?
Select an answer to reveal the explanation.
Short Explanation
Think of a stamp on the clerk’s blotter: once that upload event ID is marked done, a second knock from Event Grid doesn’t fire another paid summary.
Full Explanation
Event Grid provides at-least-once delivery for Azure Storage blob-created notifications that drive the city's document summarizer Function. When the same municipal upload event is delivered twice, an idempotent handler records the processed event identifier (or a deterministic content hash of the blob URI plus event id) in durable state before performing expensive generative work. On a replay, the Function detects the stamp and skips Azure OpenAI summarization and token spend so residents and clerks get one authoritative summary, not a double bill. This pattern preserves Event Grid's retry safety net while protecting the municipal token budget during storm-night upload floods.
Ignoring delivery identifiers and re-running full summarization on every duplicate burns tokens, can overwrite or duplicate downstream RAG index rows, and violates cost-control expectations for civic AI. Permanently disabling Event Grid retries removes recovery for transient Function or network faults, turning a poison upload into a silent miss for permit packets or ordinance PDFs. Deleting the Function app when duplicates appear is operational theater, not an idempotency design, and destroys capacity for legitimate subsequent events.
Exam caveat: AI-200 emphasizes that cloud events and queue messages are often at-least-once; correctness for generative workloads comes from application-level idempotency (processed-id store, upsert semantics, or content-addressed outputs), not from assuming exactly-once platform delivery. Distinguish this from dead-lettering, which handles poison failures after max delivery attempts rather than suppressing successful duplicate work.
Operational check: after a controlled duplicate publish of a known blob-upload event id into the municipal summarizer subscription, confirm Application Insights shows a short-circuit path, Cosmos or table storage contains the processed-id row, token metrics do not double, and the RAG or summary store still holds a single canonical artifact for that upload.