2018 is too long ago to investigate today. It is possible that there were some jobqueue updates at the time were lost and thus caused the edit or its propagation to be unable to save it in the database.

The passing of time between then and today is not indicative of a malfunction as there is no code in place that would run refreshLinks on any particular page merely for time having passed.

Upon viewing of a page, we do re-parse pages even if there were no edits to the page or any of its template links for 30 days. This ensures visitors to an article see up-to-date content automatically even in the case of temporary problems. However we do not run refreshLInks or otherwise perform database writes during page views. refreshLinks is only run on edits, or when the page is (indirectly) purged due to a relevant event (e.g. template edit, wikidata, redlink creation, bluelink deletion, etc.)

If there is no such trigger, and if the last refreshLinks attempt failed in a non-recoverable way due to a technical problem, then it remains that way until a manaul purge or null-edit, which anyone can do.

Note that, while refreshLinks can fail for any number of reasons, we have automatic re-tries of such failures so a non-recoverable failure is fortunately very rare (short of a prolonged outage, or the JobQueue failing to store the event in the first place, e.g. due to T249745.). There is a task from 2016 with some ideas about periodically running refreshLinks on all content. This would likely require some infrastructure consideration. Details at T135964: Force pages to be fully re-parsed occasionally.

Unless a pattern of more recent examples is known, or a way to reproduce this, I suggest we decline this task, or merge it into T135964.

Sounds fair enough @Krinkle!

I do with we could react to comments instead of just the task — that thumbs up was really just meant for the comment.. 😅