Documentation
¶
Overview ¶
Command notify-routing shows the notifier routing events to different receivers, escalating one nobody handles, sending an all-clear, and writing a trail that is signed and anchored as it is written, which bide audit notifications (audit.VerifyNotifications) then checks offline.
The application has two runs in one journal: a refund waiting at a 2-of-2 approval gate (alice's approvals go to the risk channel, bob's to the finance channel), and a charge that halted with an unknown outcome (it goes to on-call). The notifier is built with
- agent.WithNotifyReceiver: a named Notifier per destination (here in-process stand-ins; in production each is a notify.NewWebhook to its own URL, secret and relay);
- agent.WithNotifyRoute and agent.WithNotifyApproverRoute: where an event goes, by kind and, for an approval, by approver;
- agent.WithNotifyDeadline and agent.WithNotifyEscalation: who is told next, when the first receiver has not acknowledged in time;
- audit.NewAuditedEventStore beneath audit.NewNotifyTrail: the trail is signed and anchored as it is written, with the same audit.Signer and audit.Anchor as a journal.
It runs the story twice. In the first, every receiver answers: all events are delivered and acknowledged, the halt is resolved and its receivers get an all-clear, and the audit passes. Then a record is removed from a copy of the trail, and the audit fails. In the second, on-call's endpoint is down: after the step's deadline the lead is told, and the audit reports that on-call's acknowledgement came too late (a person was reached, but not the one the route names, in time).
It runs with no API key and no network:
go run ./examples/notify-routing
Source Files