Your listener receives Catalyst Center event notifications as JSON POSTs at /hooks/catalyst. Yesterday one notification was delivered twice and fired two identical remediation jobs, yet a later fresh occurrence of the same event type must still fire a job of its own; every log line must carry the event time and the reply must return within a couple of seconds. How should the receiver parse, de-duplicate and acknowledge each notification?
Select an answer to reveal the explanation.
Short Explanation
Your listener has three quick jobs: parse the JSON, remember the instanceId you've already handled, and send the 200 before anything slow starts. The timestamp counts epoch milliseconds, so reading it as seconds produces an incorrect, far-future time. Keying on eventId would swallow every later real occurrence, because that value names the event type rather than one delivery.
Full Explanation
The notification body carries instanceId, which identifies one delivered occurrence, so caching that value and skipping anything you've already stored blocks a redelivered copy while letting the next real occurrence through; eventId names the event definition, so keying on it would treat every later genuine occurrence as a repeat. The timestamp field arrives as Unix epoch milliseconds, so treating it as seconds produces an incorrect, far-future time and wrecks time-based correlation in your logs. Answering 200 before starting the workflow describes asynchronous handling, because the controller can treat a slow or dropped connection as a failed delivery and push the notification again. Doing the remediation first describes synchronous handling, which holds the request open long enough to invite retries and duplicate entry. Practical check: replay one captured body twice and confirm exactly one job starts, then replay it with a fresh instanceId and confirm a second job runs.