Streetlight controllers publish events to OCI Streaming. A flaky consumer may see the same message again after a failed commit, and another team may replay within the retention window after a bug fix. What delivery and retention behavior should handlers assume?
Select an answer to reveal the explanation.
Short Explanation
Streaming hands you the letter at least once and keeps a copy in the mailroom until the retention window expires—so open every letter as if it might arrive twice. Failed commits can redeliver; another consumer can replay while data is retained. There is no Queue-style delete-on-ack. Design handlers to be idempotent.
Full Explanation
OCI Streaming provides at-least-once delivery. If a flaky streetlight-event consumer fails before committing progress, it can see the same message again. Messages also remain until the stream’s retention window ends, so another team can replay within that window after a bug fix. Handlers must be idempotent: treat every message as if it might arrive twice. There is no Queue-style delete-on-acknowledgment that removes the record for everyone as soon as one consumer succeeds.
Exactly-once delivery with automatic delete-on-ack identical to OCI Queue misstates Streaming semantics. At-most-once that never allows replay while data remains retained contradicts both redelivery after failed commits and intentional replay within retention. Claiming messages vanish immediately on first read ignores configured retention hours and the log-oriented model.
Exam caveat: retention enables replay; it is not a durability SLA beyond the window. After retention elapses, messages are gone whether or not every consumer finished.
Operational check: process a message without committing, restart the consumer and confirm redelivery; after a successful commit, rewind within retention and confirm the same payload can be replayed, exercising idempotent handling both times.