dohertj2/ScadaBridge
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

fix(notifications): list sort index + CAS operator Retry/Discard (P5-3, P5-4)

Browse Source 
P5-3: add IX_Notifications_Created_NotificationId (CreatedAt DESC,
NotificationId DESC) — the Central UI Notification Outbox list page sorts on
exactly that pair, but no existing index leads unconditionally on CreatedAt,
so an unfiltered/lightly filtered page fell back to a full clustered-index
scan + sort on every COUNT + page request. Mirrors the Medium wave's
IX_SiteCalls_Created_TrackedOperationId migration + SQL twin pattern
faithfully, including the handwritten docs/plans/sql script.

P5-4: operator Retry/Discard was read-check-write keyed on NotificationId
only — a detached PipeTo task interleaving with the dispatcher's own write
(or a second concurrent operator action) could land between the read and
the write and get silently clobbered by the unconditional UpdateAsync,
stamping a Delivered row Discarded with stale fields. Adds
INotificationOutboxRepository.TryUpdateFromParkedAsync, a single-statement
compare-and-swap (WHERE Status == Parked) mirroring
SecuredWriteRepository.TryMarkApprovedAsync's CAS shape. NotificationOutboxActor's
RetryAsync/DiscardAsync now use the CAS write and, on a lost race, re-read
to report "notification already progressed to <Status>" instead of silently
overwriting whatever is there now.

Proof of failure: reverting only the actor's CAS usage while keeping the
repository addition reproduces the silent-overwrite bug — 7 tests fail,
including two new deterministic (non-sleep) race-proof tests that mock the
exact GetByIdAsync -> lost-CAS -> re-read sequence the finding describes.
P5-3 is perf-only; verified via migration/SQL-twin parity instead (no
runtime proof-of-failure is meaningful for an index).
This commit is contained in:
Joseph Doherty
2026-08-19 16:20:18 -04:00
parent 11675285af
commit 1cea01d924
12 changed files with 2607 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/ZB.MOM.WW.ScadaBridge.NotificationOutbox/NotificationOutboxActor.cs
+31 -11
View File
@@ -1109,14 +1109,25 @@ public class NotificationOutboxActor : ReceiveActor, IWithTimers
notification.NextAttemptAt = null;
notification.LastError = null;
// Zero rows updated means the row was purged between the read above and
// this write. Answer the operator honestly instead of reporting a
// re-queue that never happened — and emit no un-park audit row, because
// there is nothing to attribute it to.
if (!await repository.UpdateAsync(notification))
// Compare-and-swap on Status == Parked (arch-review 2026-08-19 P5-4). The
// read above and this write are two separate round trips; a detached
// PipeTo task can race the dispatcher's own write (or a second
// concurrent operator action) in between, so the in-memory check above
// is a fast-path rejection, not the correctness guard — a blind
// UpdateAsync here could stamp a row that has already moved on (e.g. the
// dispatcher delivered it) back to Pending with stale fields. A lost CAS
// means either the row vanished (purge) or it progressed past Parked
// under us; re-read to report which honestly instead of silently
// overwriting whatever is there now, and emit no un-park audit row in
// either case, because there is nothing to attribute it to.
if (!await repository.TryUpdateFromParkedAsync(notification))
{
var current = await repository.GetByIdAsync(request.NotificationId);
return new RetryNotificationResponse(
request.CorrelationId, Success: false, ErrorMessage: "notification not found");
request.CorrelationId, Success: false,
ErrorMessage: current is null
? "notification not found"
: $"notification already progressed to {current.Status}; retry not applied");
}
// Operator re-queued a parked notification. Emit a Submitted NotifyDeliver
@@ -1190,13 +1201,22 @@ public class NotificationOutboxActor : ReceiveActor, IWithTimers
notification.Status = NotificationStatus.Discarded;
// Same vanished-row honesty as the retry path: a purge between the read
// and the write leaves nothing to discard, so report not-found rather
// than success (and skip the terminal audit row below).
if (!await repository.UpdateAsync(notification))
// Same compare-and-swap on Status == Parked as the retry path (arch-review
// 2026-08-19 P5-4): a purge between the read and the write leaves nothing
// to discard, and a dispatcher/other-operator write landing in that same
// window (e.g. a delivery succeeding) must not be silently clobbered by a
// blind write of this stale in-memory copy. Re-read on a lost CAS to
// report which case it was, and skip the terminal audit row below either
// way — there is nothing to attribute a discard of a row that was never
// actually discarded.
if (!await repository.TryUpdateFromParkedAsync(notification))
{
var current = await repository.GetByIdAsync(request.NotificationId);
return new DiscardNotificationResponse(
request.CorrelationId, Success: false, ErrorMessage: "notification not found");
request.CorrelationId, Success: false,
ErrorMessage: current is null
? "notification not found"
: $"notification already progressed to {current.Status}; discard not applied");
}
// A manual discard is the OTHER code path that produces