ok i changed validation to be enabled for both incoming and outgoing by default.
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 https://en.wikipedia.org/wiki/Robustness_principle#Criticism
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
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 https://docs.particular.net/nservicebus/messaging/validation-fluentvalidation
I personally have always been a big fan of XSD Schema validation of the past,
I did consider doing a json.net schema variant https://www.newtonsoft.com/jsonschema
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
You do as much validation on both sides as possible.
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.
We have a similar scenario, since we are using https://docs.particular.net/transports/sql/sql-http-passthrough. 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?
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.