Release v20.58.0
Summary
Hardens Arc's command and query endpoints against hostile, null, and malformed input. Driving every command and query endpoint with adversarial input previously produced a large number of HTTP 500 responses that returned the exception message and full stack trace to the caller. Each of those cases now degrades to a clean, correct response — a 400 for bad input, a 403 for a forbidden request, a redacted error otherwise — and internal detail is no longer leaked to clients. A new analyzer catches the most common of these mistakes at authoring time.
Added
ArcOptions.ExposeExceptionDetailsto control whether command and query error responses include exception messages and stack traces. It defaults to enabled only in the Development environment.IValidationFailure— an exception implementing it is surfaced as a command validation failure (HTTP 400) instead of a server error, so code that runs inside the command pipeline can reject a command as invalid by throwing.- New analyzer ARC0013 — warns when a validator rule dereferences a member of a possibly-null concept (for example
RuleFor(c => c.Order.Value)), which throws at validation time instead of producing a validation error. Validate the concept first, or guard the rule with.When(...).
Security
- Exception messages and stack traces are no longer returned to clients in command and query responses outside the Development environment. The full detail is logged server-side and the correlation id is retained, so failures can still be traced without leaking internal information.
Fixed
- Malformed or wrong-typed command request bodies now return HTTP 400 instead of HTTP 500.
- A command validator that throws while validating hostile or partial input now returns a validation error (HTTP 400) instead of HTTP 500.
- A command that targets an aggregate but provides no usable event source id now returns a validation error (HTTP 400) instead of crashing with HTTP 500, with a client-safe message that does not leak the read model type.
- A throwing command filter no longer aborts the filter chain or masks an earlier authorization result — a forbidden request now returns HTTP 403 instead of HTTP 500.
- Observable queries no longer fail with HTTP 500 (or leak the read model type name) on an unknown sort field, and now clamp a non-positive page size to a valid page — for both MongoDB and Entity Framework Core read models.