Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Real exception is hidden when using Unobtrusive Conventions. #4000
When sending a message to an endpoint that doesn't support that message type, if you're using unobtrusive conventions then the following exception hides the real error:
If you add a reference ICommand then the exception changes to:
We see similar behavior when dealing with Timeouts, the timeout exception is masked by the unobtrusive conventions exception message.
This should be ideally be consistent regardless of the use of unobtrusive conventions as it makes the debugging process a lot harder. At the moment the decision to use unobtrusive conventions means that you mainly get that top level exception for any routing or timeout problems.
Apologies, I'm using the newest beta 6.0.0-beta0004.
The following conventions are applied to all endpoints as part of endpoint configuration (so definitely run on both):
If the handler does exist it all works as expected, but if there is a missing handler or a problem with a timeout that top error is thrown which isn't the actual exception but rather a far broader one.
@jpv001 I wasn't able to reproduce the behavior you described locally as I got the expected
My sample may misses some of your configurations or this may be fixed in more current versions of v6 which are to be released soon. If you're able to create a simple sample which reproduces the behavior you're experiencing I can take that and give it a closer look + run it against latest unstables.
I won't be in the office for a few weeks, but I'll put a spike together when I get back. We're seeing this on all of our endpoints, they all work perfectly provided there is no mapping issue, as soon as there is we get this error. Simply add ICommand and a reference to the nsb binary in the message project and it disappears.
This was referenced
Aug 4, 2016
I dug deeper into the root cause. The problem occurs only if the following points are fulfilled:
Ultimately this means:
Under these circumstances, the exception you saw will hide the fact that a message handler was not present. The log actually contains two helpful warnings in that case
I don't think it makes sense for us to optimize for such a rare case since the log file contains enough information to resolve it. You could easily mitigate it by
NSB v5 was extremely greedy in trying to load assemblies into the AppDomain. This caused all sorts of severe other problems. With v6 we no longer scanned assemblies that do not reference NSB (like said before). Which is in your special scenario a bit more inconvenient but in general still the better approach because it reduces grief with assembly scanning and increases startup time.