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:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user