From c2cd62e72a05ec0120444903e471a425a2ca04f0 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Tue, 19 May 2026 12:00:45 -0400 Subject: [PATCH] docs(requirements): note shared TrackedOperationId model in notification docs --- docs/requirements/Component-NotificationOutbox.md | 2 ++ docs/requirements/Component-NotificationService.md | 1 + 2 files changed, 3 insertions(+) diff --git a/docs/requirements/Component-NotificationOutbox.md b/docs/requirements/Component-NotificationOutbox.md index bd26149..612ae47 100644 --- a/docs/requirements/Component-NotificationOutbox.md +++ b/docs/requirements/Component-NotificationOutbox.md @@ -78,6 +78,8 @@ All timestamps are UTC. - `Parked` — terminal-not-delivered: a permanent failure, or retries exhausted. `LastError` distinguishes which. - `Discarded` — terminal, reached **only by operator action** on a parked notification. The row is kept (not deleted) so the table remains a complete audit record. +The Notification Outbox and the central [`Site Call Audit`](Component-SiteCallAudit.md) component share the `TrackedOperationId` tracking model and this status lifecycle, but differ in delivery locality: the Notification Outbox **delivers** notifications itself (central SMTP), whereas Site Call Audit only **audits** cached calls delivered site-locally by the site Store-and-Forward Engine — it is not a dispatcher. + ### Retry Policy Delivery retry reuses the central SMTP configuration's max-retry-count and fixed retry interval. The interval is fixed (no exponential backoff), consistent with the existing fixed-interval store-and-forward convention. diff --git a/docs/requirements/Component-NotificationService.md b/docs/requirements/Component-NotificationService.md index c2de73f..f419826 100644 --- a/docs/requirements/Component-NotificationService.md +++ b/docs/requirements/Component-NotificationService.md @@ -61,6 +61,7 @@ NotificationStatus status = Notify.Status(id); - `Notify.To("listName").Send(...)` is **asynchronous**: it generates a `NotificationId` (GUID) locally, hands the notification to the site Store-and-Forward Engine for forwarding to central, and returns the `NotificationId` to the script **immediately**. The script does not block waiting for delivery. - The message body is **plain text** only. No HTML content. - `Notify.Status(notificationId)` returns a small **status record** — the current status, retry count, last error, and key timestamps (enqueued, delivered). While the notification is still in the site Store-and-Forward buffer, the site answers the query **locally** with status `Forwarding`; once forwarded to central, the query round-trips to central and reads the `Notifications` table. +- The returned `NotificationId` is a `TrackedOperationId` — the shared Commons tracking-handle type used by all store-and-forward producers; `NotificationId` is simply the notification-domain name for it. Likewise, `Notify.Status` is a thin alias of the unified `Tracking.Status` accessor, retained for backward compatibility. This is a naming/type clarification only — notification delivery behavior is unchanged. ## Notification Delivery Behavior