fix(driver-historian-wonderware): resolve Medium code-review finding (Driver.Historian.Wonderware-002)

Normalise req.Events to Array.Empty<AlarmHistorianEventDto>() immediately
after MessagePack deserialization in HandleWriteAlarmEventsAsync. MessagePack
deserializes an absent or explicit-nil array field as null, not Array.Empty,
so a peer that sends a null Events array would trigger a NullReferenceException
on either .Length dereference (no-writer branch or catch block), leaving the
client correlation-id wait hanging with no reply frame.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joseph Doherty
2026-05-22 09:21:46 -04:00
parent 6bb971c040
commit 205b07f6aa
2 changed files with 7 additions and 2 deletions

View File

@@ -63,7 +63,7 @@ the reconnect path can re-open with `ReadOnly = false`) or at minimum as
| Severity | Medium |
| Category | Correctness and logic bugs |
| Location | `Ipc/HistorianFrameHandler.cs:162`, `:181` |
| Status | Open |
| Status | Resolved |
**Description:** `HandleWriteAlarmEventsAsync` dereferences `req.Events.Length`
in both the `_alarmWriter is null` branch (line 162) and the catch block (line
@@ -79,7 +79,7 @@ already null-guards `events`; the frame handler does not.
immediately after deserialization (or guard each `.Length` access), consistent
with the null-tolerance the writer already has.
**Resolution:** _(open)_
**Resolution:** Resolved 2026-05-22 — normalise `req.Events` to `Array.Empty<AlarmHistorianEventDto>()` immediately after deserialization so all subsequent `.Length` accesses are safe against null frames.
### Driver.Historian.Wonderware-003