Closed reitzig closed 3 years ago
I am not convinced that this isn't an error. If you just have a single configuration I would consider this an error if none of my scenarios match. What is you log statement, if none of the scenarios of all configuration match?
Despite that, we will support your use case with multiple configuration with one of the next versions which supports using multiple configuration with a single validator instance.
I don't reject the PR yet, but need more opinions and convincing arguments on that
What is you log statement, if none of the scenarios of all configuration match?
We reject the request and log an error, of course. I guess the main point is that the application has to decide what constitutes an error and what doesn't; the library does not know.
In our case, operations (not us, alas) considers every ERROR line in the log to be something to act on, so we actually got them on the (proverbial) phone telling us something was broken.
Despite that, we will support your use case with multiple configuration with one of the next versions which supports using multiple configuration with a single validator instance.
Sounds good! What are the semantics you'll consider? For reference, we have three configurations A, B, C and our predicate is A && (B || C)
. I would assume you had A && B && C
in mind, which would unfortunately not help us.
FWIW, we're absolutely fine with performing and handling the three calls in our application; as I said, we consider that part of the "business logic".
Currently, when finding that an input is invalid (= no matching scenarios found), we get this log message:
As per usual, we've set the log level of the validator dependency to WARN, so we see only this message. This is problematic since we always validate against multiple configurations (our documents can be one or the other) so we always get this error message, even on ("fachlich") valid inputs, which confuses our operators.
Please