After an Events rule matches, what is the service’s responsibility versus the destination’s, and how should multi-step follow-up be designed?
Select an answer to reveal the explanation.
Short Explanation
Events matches and delivers; the Function, topic, or stream then does what you configured. It is not a workflow engine that waits on a Function’s return to pick step two—put chaining inside the function or on a later resource-change rule.
Full Explanation
After an Events rule matches, Events’ responsibility is to deliver the CloudEvent payload to each named destination; each destination then processes according to its own model. A Function runs your code; a topic notifies subscribers; a stream stores the record for consumers. Multi-step follow-up belongs inside the Function (or another rule that matches a later resource change the first step caused)—not inside Events as a waiting orchestrator. Events does not run a built-in step-function workflow that waits on the Function return body before choosing the next OCI service; delivery is push-and-done from Events’ perspective. Events does not block until every Streaming consumer commits offsets and then mark the rule complete—Streaming consumers are independent of the rule’s delivery acknowledgment. Events does not delete the source OCI resource after delivery to guarantee exactly-once orchestration; resource lifetime remains owned by the emitting service and your automation. Exam caveat: at-least-once delivery expectations mean Functions and downstream consumers should be idempotent if the same CloudEvent can be processed more than once under retry. Operational check: implement chaining by having the Function create a well-defined follow-up resource or message, then either continue work in-process or add a second rule on that subsequent change—and verify with logs that step two never depends on Events interpreting the Function’s return value.