geekeey/request
Watch
2
0
Fork
You've already forked request
 0
Code Issues Pull requests Projects Releases Packages 3 Wiki Activity Actions

fix(validation): make Severity meaningful in Validation.IsValid

Browse source 
Validation.IsValid previously counted every problem regardless of severity,
leaving Severity inert. Now IsValid only fails on Error problems, so Warning
and Info no longer invalidate the result, and IsValidFor(Severity) lets
callers set the failing-severity threshold.
This commit is contained in:
Louis Seubert 2026-07-12 18:50:06 +02:00
commit f7263c33a8
Signed by: louis9902
GPG key ID: 4B9DB28F826553BD
4 changed files with 75 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

1
CHANGELOG.md
View file

@ -53,6 +53,7 @@ To have a consistent experience across all packages, some public interfaces have
- **request.result:** Fold `IsSuccess` into `Result<T>.GetHashCode` to avoid collisions between a failure and a success value whose hash is `0`
- **request.validation:** Guard null comparison bounds in `GreaterThan`/`LessThan`/`Between` etc. so a `null` bound no longer throws (`NullReferenceException`)
- **request.validation:** Return no problems when validating a `null` instance of a reference type instead of dereferencing it (`NullReferenceException`)
- **request.validation:** Make `Severity` meaningful — `Validation.IsValid` now only fails on `Error` problems; `Warning`/`Info` no longer invalidate. Added `Validation.IsValidFor(Severity)` to set the failing-severity threshold (see PLAN.md Inconsistencies#B)
### Removed