As an interim workaround, I've put together a quick-and-dirty script to slowly do a rolling purge of items using pywikibot. It identifies all items that have not been edited since before the formatter URL was changed, generates a list, and works through them. As it uses the PWB framework it respects maxlag, and will back off if overloaded.

https://github.com/generalist/wikidata-misc/blob/master/wikidata-purge.sh

Works fine for small sets of items, but maxlag-related delays mean it's probably not a practical solution for very heavily used properties.

In T112081#6100884, @agray wrote:

As an interim workaround, I've put together a quick-and-dirty script to slowly do a rolling purge of items using pywikibot. It identifies all items that have not been edited since before the formatter URL was changed, generates a list, and works through them.

Is this scheduled?

For example we noticed that P6288 should be purged.

In T112081#6404998, @valerio.bozzolan wrote:

Is this scheduled?

For example we noticed that P6288 should be purged.

It's not scheduled in any way - just an as-needed backup - but I'll run it for P6288 today.

It has occurred to me today that this problem is (in some ways) a blessing in disguise - it helps mitigate against the effects of vandalism by deleting or changing a formatter URL.

If we do manage to solve this eg by having a server-side script purge items after the formatter URL changes, maybe it would be good to build in a natural delay - say it only runs twelve hours after the changes, or checks for new formatter URLs once a day, or something.

After purging a property and an item where the property is used, it still seems to be cached somewhere, and if a property is added after the formatter URL is changed, the link created is based on the old formatter URL.

Property information, probably including the formatter URL, is cached for 24 hours; as far as I can tell, there’s no way to actively purge that cache.