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

fix(dispatcher): throw on ambiguous handlers instead of silent .First()

Browse source 
Multiple handlers for the same request were previously resolved via .First(),
with ordering depending on Type.GetInterfaces() order (non-deterministic).
Now ScalarRequestInvoker/StreamRequestInvoker throw InvalidOperationException
listing the candidate handlers when more than one matches.
This commit is contained in:
Louis Seubert 2026-07-12 19:18:21 +02:00
commit f79e8780f7
Signed by: louis9902
GPG key ID: 4B9DB28F826553BD
7 changed files with 134 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

1
CHANGELOG.md
View file

@ -54,6 +54,7 @@ To have a consistent experience across all packages, some public interfaces have
- **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)
- **request.dispatcher:** Throw `InvalidOperationException` listing candidates when multiple handlers match a request instead of silently resolving via `.First()` (matches MediatR). Also throws when no handler is registered (see PLAN.md Inconsistencies#C)
### Removed