A transit authority calls PutEvents and does not set an event bus name. The rule that should match those events is on a custom bus, and the rule never runs. What is going wrong?
Select an answer to reveal the explanation.
Short Explanation
You dropped the letter in the building's front mailbox while the clerk watches a private slot. The PutEvents call names no event bus, so the event goes to the default bus, and your rule on the custom bus never sees it. Rewriting the pattern on the custom bus cannot match an event that arrived on a different bus.
Full Explanation
PutEvents delivers to the default event bus when the request does not name a bus. A rule evaluates only the bus it is attached to, so a rule on the custom bus ignores events that landed on the default bus. The rule never runs because the event is on the other bus, not because the pattern failed a comparison. Name the custom bus on PutEvents, or move the rule to the default bus if that is where these events are supposed to stay. A schema registry documents event shape and does not accept or reject the put. Custom-bus rules do not also read the default bus, so editing the pattern still matches nothing. PutEvents is not a write to CloudTrail; the trail may record the API call, and the event payload lives on the bus that was targeted. Caveat: events already on the default bus are not moved when the publisher is fixed later, so those need a rule on the default bus or a resend. Operational check: put one test event with the custom bus name set and confirm the rule matches it, then confirm a call with no bus name does not.