| mmodell added a comment. |
In T215380#4944667, @thcipriani wrote:+1
Having this show up as in ERROR means we see it on the dashboards in logstash that we use to determine if something went wrong when we deploy. This problem doesn't indicate something is wrong with code/data/environment/config, but just an unhandled (but known and understood) data state that could cause spikes in error logs that reduce our confidence in a deployment.
I'm not really sure what transient condition caused it to spike and then subside, however, I believe it's an indicator of a somewhat problematic trend: I've noticed quite a lot of instances similar to this where api-level or library level code is written to strictly and thoroughly validate data, complete with many specific exceptions that log as ERROR. Meanwhile callers of said code are much less thorough and so un-handled errors are regularly bubbling up into fatalmonitor. I don't think we can expect a revolutionary improvement in the discipline of developers calling these APIs but I do think that it's fair to ask the developers implementing thorough validation regimens to exercise some discipline in exception level logging.
What might be the best venue to advocate for better error level classification when raising exceptions? It seems fairly obvious to me that this (and similar) validation errors should be DEBUG or INFO level as they are only useful to the consumer of an API and not relevant to the overall health and operation of the software itself.
Thinking about this a bit deeper, what it seems like we need is a way to differentiate between user-input-validation-exceptions and filter them out of deployment dashboards, etc. These are only bugs in the sense that front-end code should have caught the exception. In the case of an API call coming from 3rd party callers there is absolutely nothing we can do to act on the error and it's not at all useful to surface it in places where we regularly monitor for operational or deployment-related issues.
Cc: thcipriani, Daimona, Lydia_Pintscher, Addshore, Aklapper, mmodell, Nandana, Lahi, Gq86, Darkminds3113, GoranSMilovanovic, QZanden, LawExplorer, Vali.matei, _jensen, Jonas, Volker_E, Wikidata-bugs, aude, GWicke, Dinoguy1000, Jdforrester-WMF, Mbch331, Jay8g, Krenair
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
