ok i changed validation to be enabled for both incoming and outgoing by default.
@mookid8000
basically apply two sets of validation: a stricter one for outgoing messages, and a more forgiving one for incoming
I am not sure that is a good idea. see Robustness principle - Wikipedia
I think there is a scenario, when expectations/assumptions on messages need to change, and there is a message is in-flight. but i thought that would be handled either by a message mutator or serializer configurations?
I am happy to consider diff validations for incoming and outgoing, but not sure if the above is enough justification? I would perhaps prefer
@ramonsmits
I’m all in on option 3 (Message is invalid, move to error queue), and move it to the error queue ASAP instead of cycling through all immediate and delayed retries as a schema validation error is not a transient error.
yep that is the current behavior and it is in the doco Community extensions and integrations • NServiceBus • Particular Docs
I personally have always been a big fan of XSD Schema validation of the past,
I did consider doing a json.net schema variant Json.NET Schema - Newtonsoft
@SzymonPobiega
That works within a single trust domain i.e. when the same party controls both the sender and the receiver.
I think that works when u have a very small domain + small team. as it grows to many endpoints+teams+message contracts, i think those message contract assumptions+validations need to be formalised
@Dennis
You do as much validation on both sides as possible.
Agreed
You check as much as you can sender-side. You can create validation logic and deploy that both at the sender and the receiver.
We are shipping our validators inside our message assembly, then scanning all *.Messages.dll assemblies for validators.
If you SPA needs json, why not feed it json directly from a DocumentDb that stores json? There are even DocumentDB that support hosting javascript for validating incoming data, if someone tries to circumvent the javascript in the SPA. And this example is even without messaging.
We have a similar scenario, since we are using Community extensions and integrations • NServiceBus • Particular Docs. essentially place the http request directly on the sql table. We do validation on message type/namespace and destination, then full message validation is done on the receiver.
Also, as mentioned above, using a json schema before “feed it json directly from a DocumentDb” might be a viable approach?
@boblangley
Should a data validation error go to the error queue? Messages in the error queue should be retryable without modification.
Unfortunately that is not always possible. Often u have bugs which cause message content to be problematic, and it needs to be fixed prior to a retry
Instead, shouldn’t validation errors be handled via an explicit business process?
Some validations map well to having an explicit business process, other do not. A business user doesnt care that a Guid property should not be Guid.Empty
and no business process needs to happen if one is detected.