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

review(Driver.Modbus.Cli): FlushLogging() + interval validation + banner-before-events

Browse Source 
Re-review at 7286d320. -009 FlushLogging() in finally; -010 validate --interval-ms positive
(+8 tests); -011 print subscribe banner before wiring OnDataChange (no main/poll-thread
interleave). Parity with AbCip.Cli.
This commit is contained in:
Joseph Doherty
2026-06-19 12:08:45 -04:00
parent 754c5a3684
commit b0f9b8016a
6 changed files with 205 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
code-reviews/Driver.Modbus.Cli/findings.md
+103 -3
View File
@@ -4,12 +4,12 @@
|---|---|
| Module | `src/Drivers/Cli/ZB.MOM.WW.OtOpcUa.Driver.Modbus.Cli` |
| Reviewer | Claude Code |
| Review date | 2026-05-22 |
| Commit reviewed | `76d35d1` |
| Review date | 2026-06-19 |
| Commit reviewed | `7286d320` |
| Status | Reviewed |
| Open findings | 0 |
## Checklist coverage
## Checklist coverage (initial review 2026-05-22, commit `76d35d1`)
A comprehensive review completes every category, recording "No issues found" where
a category produced nothing rather than leaving it blank.
@@ -27,6 +27,25 @@ a category produced nothing rather than leaving it blank.
| 9 | Testing coverage | Driver.Modbus.Cli-008 |
| 10 | Documentation & comments | No issues found |
## Re-review 2026-06-19 (commit 7286d320)
All eight prior findings were Resolved. This re-review covers the full module at HEAD.
#### Checklist coverage (re-review 2026-06-19)
| # | Category | Result |
|---|---|---|
| 1 | Correctness & logic bugs | Driver.Modbus.Cli-011 |
| 2 | OtOpcUa conventions | No issues found |
| 3 | Concurrency & thread safety | No issues found |
| 4 | Error handling & resilience | No issues found |
| 5 | Security | No issues found |
| 6 | Performance & resource management | Driver.Modbus.Cli-009 |
| 7 | Design-document adherence | No issues found |
| 8 | Code organization & conventions | No issues found |
| 9 | Testing coverage | No new gaps (72 tests passing) |
| 10 | Documentation & comments | Driver.Modbus.Cli-010 (input validation gap, low) |
## Findings
### Driver.Modbus.Cli-001
@@ -278,3 +297,84 @@ previously untested branch logic:
`ReadCommand` / `WriteCommand` for finding 005.
Total test count grew from 18 to 64; all pass.
### Driver.Modbus.Cli-009
| Field | Value |
|---|---|
| Severity | Low |
| Category | Performance & resource management |
| Location | `src/Drivers/Cli/ZB.MOM.WW.OtOpcUa.Driver.Modbus.Cli/Commands/ProbeCommand.cs:68`; `ReadCommand.cs:86`; `WriteCommand.cs:112`; `SubscribeCommand.cs:129` |
| Status | Resolved |
**Description:** `FlushLogging()` (defined in `DriverCommandBase`) is never called in any of
the four Modbus CLI command `finally` blocks. Serilog's default console sink buffers output;
without `Log.CloseAndFlush()` before process exit, log lines emitted during
`ShutdownAsync` (especially on Ctrl+C of a long-running `subscribe`) can be silently
dropped. The sibling `Driver.AbCip.Cli` calls `FlushLogging()` in every command's `finally`
block (with a `// Driver.AbCip.Cli-005` reference to the finding that introduced it); the
Modbus CLI was never brought in line with that pattern.
**Recommendation:** Add `FlushLogging();` as the last statement in the `finally` block of
each command's `ExecuteAsync`, mirroring `Driver.AbCip.Cli`. No test is needed for this
mechanical addition — the behaviour (Serilog flush) is not unit-testable without mocking
the global logger.
**Resolution:** Resolved 2026-06-19 — added `FlushLogging();` as the last statement in the
`finally` block of `ProbeCommand`, `ReadCommand`, `WriteCommand`, and `SubscribeCommand`,
each annotated with a `// Driver.Modbus.Cli-009` comment. Mirrors `Driver.AbCip.Cli`.
### Driver.Modbus.Cli-010
| Field | Value |
|---|---|
| Severity | Low |
| Category | Error handling & resilience |
| Location | `src/Drivers/Cli/ZB.MOM.WW.OtOpcUa.Driver.Modbus.Cli/Commands/SubscribeCommand.cs:36` |
| Status | Resolved |
**Description:** `SubscribeCommand`'s `--interval-ms` option (`int IntervalMs`, default 1000)
has no validation guard. Passing `--interval-ms 0` or a negative value produces a
non-positive `TimeSpan.FromMilliseconds(IntervalMs)` handed to `driver.SubscribeAsync`, which
propagates deep into `PollGroupEngine` and surfaces as an opaque downstream failure rather
than a clean operator error. The sibling `Driver.AbCip.Cli.SubscribeCommand` introduced
`ValidateInterval(int intervalMs)` (Driver.AbCip.Cli-004) to guard this; the Modbus CLI
was never updated to match.
**Recommendation:** Add an `internal static void ValidateInterval(int intervalMs)` method to
`SubscribeCommand` (mirroring the AbCip sibling) that throws `CommandException` for
non-positive values, and call it at the top of `ExecuteAsync` after `ValidateEndpoint()`.
**Resolution:** Resolved 2026-06-19 — added `SubscribeCommand.ValidateInterval(int intervalMs)`
(throws `CommandException` for `<= 0`) and called it after `ValidateEndpoint()` in
`ExecuteAsync`. New `SubscribeCommandValidationTests` class with 3+4+1 = 8 tests covers the
valid / invalid boundary and the end-to-end rejection via `ExecuteAsync`. Total test count
grew from 64 to 72.
### Driver.Modbus.Cli-011
| Field | Value |
|---|---|
| Severity | Low |
| Category | Correctness & logic bugs |
| Location | `src/Drivers/Cli/ZB.MOM.WW.OtOpcUa.Driver.Modbus.Cli/Commands/SubscribeCommand.cs:119-122` |
| Status | Resolved |
**Description:** The "Subscribed to … Ctrl+C to stop." banner was printed (`WriteLineAsync`)
**after** `driver.SubscribeAsync` returned, meaning the `PollGroupEngine` background thread
could already be delivering `OnDataChange` events to `console.Output.WriteLine` while the
banner was still being awaited on the main thread. `TextWriter.WriteLine` is not guaranteed
thread-safe, so the banner and the first change-event line could interleave or tear. The
sibling `Driver.AbCip.Cli.SubscribeCommand` explicitly prints the banner **before** wiring
`OnDataChange` (with a `// Driver.AbCip.Cli-003` comment explaining the ordering contract);
the Modbus CLI was never updated to match.
**Recommendation:** Move the `WriteLineAsync` banner to immediately after `InitializeAsync`
and before `OnDataChange` is wired, so the main-thread write is guaranteed to complete before
the poll thread can write change events. This matches the AbCip ordering.
**Resolution:** Resolved 2026-06-19 — moved the banner `WriteLineAsync` to immediately after
`InitializeAsync` and before the `OnDataChange` handler is attached, eliminating the race
with the first poll-thread event. Annotated with `// Driver.Modbus.Cli-011` reference.
No separate test required — the fix is a purely structural ordering change, and the existing
`CommandCancellationTests` continue to pass.