test(auditlog): end-to-end ExecutionId correlation + docs
This commit is contained in:
@@ -83,6 +83,7 @@ row per lifecycle event across all channels.
|
||||
| `Channel` | `varchar(32)` | `ApiOutbound` \| `DbOutbound` \| `Notification` \| `ApiInbound`. |
|
||||
| `Kind` | `varchar(32)` | Event kind discriminator (see kinds list below). |
|
||||
| `CorrelationId` | `uniqueidentifier` NULL | Ties multi-event operations together. `TrackedOperationId` for cached calls, `NotificationId` for notifications, request-id for inbound API. NULL for sync one-shot calls. |
|
||||
| `ExecutionId` | `uniqueidentifier` NULL | The originating script execution / inbound request — the universal per-run correlation value; distinct from `CorrelationId`, which is the per-operation lifecycle id. Stamped on *every* audit row emitted by one execution. |
|
||||
| `SourceSiteId` | `varchar(64)` NULL | NULL for central-originated events. |
|
||||
| `SourceInstanceId` | `varchar(128)` NULL | Instance whose script initiated the action (when applicable). |
|
||||
| `SourceScript` | `varchar(128)` NULL | Script name within the instance. |
|
||||
@@ -103,6 +104,7 @@ row per lifecycle event across all channels.
|
||||
- `IX_AuditLog_OccurredAtUtc` — primary time-range index for global scans.
|
||||
- `IX_AuditLog_Site_Occurred (SourceSiteId, OccurredAtUtc)` — per-site filters.
|
||||
- `IX_AuditLog_Correlation (CorrelationId)` — drilldown from a single operation.
|
||||
- `IX_AuditLog_Execution (ExecutionId)` — drilldown to every action of one script execution / inbound request.
|
||||
- `IX_AuditLog_Channel_Status_Occurred (Channel, Status, OccurredAtUtc)` — KPI / dashboard tiles.
|
||||
- `IX_AuditLog_Target_Occurred (Target, OccurredAtUtc)` — "what did we send to system X".
|
||||
- Monthly partitioning on `OccurredAtUtc` from day one; purge is a partition switch (see Retention & Purge).
|
||||
@@ -126,6 +128,27 @@ Inbound API is intentionally collapsed to a single `InboundRequest` (or
|
||||
`InboundAuthFailure` for auth rejections) row per request rather than a
|
||||
multi-event lifecycle.
|
||||
|
||||
### `ExecutionId` vs `CorrelationId`
|
||||
|
||||
The table carries two correlation columns at different granularities:
|
||||
|
||||
- **`ExecutionId`** is the *universal per-run* value: one id per script
|
||||
execution (tag-change / timer-triggered or otherwise) or per inbound API
|
||||
request. It is stamped on **every** audit row that run produces — the sync
|
||||
`ApiCall` and `DbWrite` rows, the full cached-call lifecycle, the
|
||||
`NotifySend` / `NotifyDeliver` rows, and the inbound row alike. A run that
|
||||
performs no trust-boundary action emits no rows, but any run that emits
|
||||
multiple rows ties them all together under one `ExecutionId`. This lets an
|
||||
audit reader pull the complete trust-boundary footprint of a single script
|
||||
run with one `ExecutionId` filter.
|
||||
- **`CorrelationId`** is the *per-operation lifecycle* id — it groups the
|
||||
multiple events of one long-running operation (`TrackedOperationId` for a
|
||||
cached call, `NotificationId` for a notification, request-id for inbound
|
||||
API) and is NULL for sync one-shot calls that have no operation lifecycle.
|
||||
|
||||
The two are orthogonal: one execution may touch several operations (each with
|
||||
its own `CorrelationId`) yet every resulting row shares the one `ExecutionId`.
|
||||
|
||||
## The Site-Local `AuditLog` (SQLite)
|
||||
|
||||
A SQLite database file on each site node, alongside the Store-and-Forward
|
||||
|
||||
Reference in New Issue
Block a user