We are sometimes (not sure how much, maybe we could at least log this) running into the PARSE_THRESHOLD_SEC limit when running refreshlinks jobs on wikidata.
the parseroutput is generated without html and then it is cached. then when viewing an item, it has no html at all.
locally, generating parseroutput in refreshlinks takes ~1.1 seconds if my item has a statement. without statements, it is ~0.9 seconds. I suppose production machines are more powerful than my laptop and maybe hitting more than a second is more rare but we have reports / cases of this bug happening. (especially with larger items? and depending on timing of refreshlinks)
i am not sure we should be doing caching there, without the html. or maybe the parser options / key should be different? or the parseroutput should include html there?
suppose we can work around the problem in wikibase for now, but not entirely happy with doing that vs. changing how this is done in core.
