But what is the sender made an error and is unaware or maybe the sender just passed data that it received in error?
So what if the sender doesn’t do validation, it accidentally inserted a null value, you do not check this and now you have corrupted data in your system because the receiver didn’t validate?
Basically there are 4 options:
- Message is valid, process
- Message is invalid, process
- Message is invalid, move to error queue
- Message is invalid, discard
I’m all in on option 3, 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.
It then ends up in the error queue and you can either choose do archive the message and do any manual task needed or as stated before add a compensating action. You can JIT fix the message, so that it now does pass validation, or you can manually discard the message, you deploy this, and you retry the message which now does result in processing successfully without any change of corrupting your system. Meaning, the message eventually gets processed.
I’ve almost never seen systems that have well though out error flows or very good input validation. IMHO you should take validation steps to ensure you are not accidentally corrupting your business data because of rogue or erroneous input. I personally have always been a big fan of XSD Schema validation of the past, tightening schemas as much as possible and saved me many many times and gave opportunities to process incoming data differently because you explicitly develop such alternate flows based on the validation which grows over time.
Regarding postels law, yes definitely, the recipient should be as liberal as it can be, but still require validation.