A bridge-maintenance ChatOps bot must react when someone types /fail-over in the ops Webex space. Which construction avoids polling GET /messages?
Select an answer to reveal the explanation.
Short Explanation
Don’t keep opening the mailbox every second—leave a doorbell (webhook) for new messages. Register messages/created with a public targetUrl and usually a roomId filter for that ops space.
Full Explanation
Reactive ChatOps without polling means registering for events: POST a webhook with resource messages, event created, a publicly reachable HTTPS targetUrl, and usually a roomId filter scoped to the bridge-maintenance ops space. Webex then POSTs notifications when new messages appear, and the bot can react to /fail-over without hammering GET /messages on a timer.
An infinite loop of GET /messages every 200 ms is the polling anti-pattern—wasteful, noisy, and rate-limit prone. Subscribing only to Webex Devices presence events and inferring commands from mute state ignores message content entirely. Paging historical messages with Domain 2 next links looks backward through archives for a string and is not a live command channel for fail-over. Validate webhook signatures or secrets on the targetUrl handler before acting on /fail-over. Keep the public endpoint dedicated to Webex events so bridge-maintenance command handling is not mixed with unrelated municipal web traffic.
Exam caveat: webhooks need a reachable target and proper validation; room filters reduce noise to the intended municipal ops space. Operational check: create the messages/created webhook with a roomId filter, post /fail-over in that space under required mention rules, and confirm the bot’s targetUrl receives the event with no polling loop visible in process lists.