@Lydia_Pintscher the only way to fix this is to increase the entity size limit. :)
Wich we can and I think we should do!

As reported by mediawiki the entity is 3,618,510 bytes

(For the record, it happens every time the entity is edited, which is roughly 900 times in the last 12 hours.)
I must also say that such a big page is pretty slow to load, so while increasing the size limit would fix this specific problem, it could lead to performance issues.

This seems like a error that should be handled gracefully in the UI instead of bubbling up to the fatal monitor. I'd be satisfied if we simply reported this as a DEBUG or INFO level log entry. (or even as WARNING)

Looks like we haven't seen this in fatalmonitor since 2019-02-09T08:45, but it doesn't look like the code has been updated at all. Did something change recently?

In T215380#4932826, @mmodell wrote:

This seems like a error that should be handled gracefully in the UI instead of bubbling up to the fatal monitor. I'd be satisfied if we simply reported this as a DEBUG or INFO level log entry. (or even as WARNING)

+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.

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 with their error handling code. This results in un-handled errors regularly bubbling up to 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.

From a quick look at https://www.wikidata.org/wiki/Q27972199 its property Main suject (P921) has a lot of duplicates. An example is conserved Plasmodium protein, unknown function which shows up more than a thousand time.

The page history shows recent statements have been done by User:QuickStatementsBot. Maybe it is broken and inserted a lot of duplicates?

The bot is operated by @Magnus . Can you please check claims maid on Q27972199? Seems like it is full of duplicates ;)

So here is what happens: I create(d) lots of gene/protein items (example) for various species. For many statements, I can create references, as I get them from the upstream source. That paper is one of the often-cited ones, about a determination method.

What I also do is add the gene/protein in question as the "main subject" of the publication item. In most cases that makes sense, but not in that particular case.
I have now limited P921 for all publications to 100 entries, that should prevent this from happening again.

The P921 in the item in question can be removed (no, they are not duplicates, the code checks for those).

Update: Will remove them with QuickStatements now

Removal is running.

This seems to be the only item affected with so many P921.

We believe to have fixed to change the behaviour in T217741 so that the error is handled in the UI (i.e. exception is caught).
Is the error still occurring in logs?

Looks like this has now not happened since March 1st

addshore@mwlog1001:~$ zgrep -cF "Content too big! Entity: Q" /srv/mw-log/archive/exception.log-20190* | grep -v ":0"
/srv/mw-log/archive/exception.log-20190214.gz:10
/srv/mw-log/archive/exception.log-20190226.gz:36
/srv/mw-log/archive/exception.log-20190228.gz:6590
/srv/mw-log/archive/exception.log-20190301.gz:3772