AI-generated audit finding — this issue was opened from an automated security/correctness audit. It has not been triaged by a human yet; verify the reasoning, reproducibility, and severity before acting on it.
Medium: LoggerMiddleware treats DispatchException as a failed dispatch even though IceRPC converts it into a normal non-OK response — CONFIRMED
Affected code:
Verification:
Confirmed. LoggerMiddleware.DispatchAsync wraps _next.DispatchAsync in a generic catch (Exception) at line 47. Any exception — including the library-idiomatic DispatchException used to signal NotFound, InvalidData, etc. — is logged with the DispatchException event and rethrown.
The protocol connection above the middleware then catches the rethrown DispatchException and turns it into a perfectly normal response with the carried status code. Operators see a double-signal: a "failed dispatch" log entry and a non-OK response, even though the library treats the flow as normal.
Impact:
- Server logs misclassify expected application outcomes as exceptional failures.
- Alerting and dashboards built on the
DispatchException event ID or on exception-shape log queries overcount failures.
- Middleware logging contract diverges from the rest of IceRPC.
Recommendation:
- Add a
catch (DispatchException dispatchException) { LogDispatch(...dispatchException.StatusCode...); throw; } branch before the general handler, or restructure so logging happens after the protocol-connection conversion.
- Add regression tests that throw
DispatchException(StatusCode.NotFound) and DispatchException(StatusCode.InvalidData) and assert the Dispatch event (not DispatchException) is emitted.
Status: Valid, Medium severity.
Source report: src-IceRpc.Logger-audit-2026-04-14.md (finding ``LoggerMiddlewaretreatsDispatchException` as a failed dispatch even though IceRPC converts it into a normal non-OK response — CONFIRMED`)
Severity (auditor-assigned): Medium
Medium:
LoggerMiddlewaretreatsDispatchExceptionas a failed dispatch even though IceRPC converts it into a normal non-OK response — CONFIRMEDAffected code:
try { … } catch (Exception) { LogDispatchException(...); throw; }with no special-case forDispatchExceptionDispatchExceptionis the standard way to signal a non-OK responseDispatchExceptioninto anOutgoingResponsewithStatusCode = dispatchException.StatusCodeVerification:
Confirmed.
LoggerMiddleware.DispatchAsyncwraps_next.DispatchAsyncin a genericcatch (Exception)at line 47. Any exception — including the library-idiomaticDispatchExceptionused to signalNotFound,InvalidData, etc. — is logged with theDispatchExceptionevent and rethrown.The protocol connection above the middleware then catches the rethrown
DispatchExceptionand turns it into a perfectly normal response with the carried status code. Operators see a double-signal: a "failed dispatch" log entry and a non-OK response, even though the library treats the flow as normal.Impact:
DispatchExceptionevent ID or on exception-shape log queries overcount failures.Recommendation:
catch (DispatchException dispatchException) { LogDispatch(...dispatchException.StatusCode...); throw; }branch before the general handler, or restructure so logging happens after the protocol-connection conversion.DispatchException(StatusCode.NotFound)andDispatchException(StatusCode.InvalidData)and assert theDispatchevent (notDispatchException) is emitted.Status: Valid, Medium severity.
Source report: src-IceRpc.Logger-audit-2026-04-14.md (finding ``LoggerMiddleware
treatsDispatchException` as a failed dispatch even though IceRPC converts it into a normal non-OK response — CONFIRMED`)Severity (auditor-assigned): Medium