This is an issue with archive.today. Please use the long-form versions of archive.today snapshots.

Ex: Instead of https://archive.ph/18GH9, use http://archive.today/20220922072433/https://www.parool.nl/nieuws/station-noorderpark-vernuft-als-een-cobra~bfa78dba/

Ok, that's... weird. Note that anything with archive.today redirects to archive.ph (including the link above), but it appears that neither http://archive.today/20220922072433.... nor http://archive.ph/20220922072433.... used in this article triggers the bot into changing it the way I described in the initial report (Diffs 1, 2), so despite getting the longer form being a bit more inconvenient it seems like a reasonable alternative.

In T320969#8321726, @Styyx wrote:

so despite getting the longer form being a bit more inconvenient it seems like a reasonable alternative.

technically it should be the long form anyway per https://en.wikipedia.org/wiki/Help_talk:Using_archive.today#RfC:_Should_we_use_short_or_long_format_URLs?

Code is being tested.

Old behavior of the bot is that any archive URL that couldn't be validated directly from the URL, needed to be validated by making a request to the archive provider. If the request fails for any reason, the archive URL would fail validation and the archive URL would be considered invalid, resulting in subsequent replacement on wiki. The original solution was to have the archive provider simply exempt the bot from anti-bot checks, but this never happened.

The new behavior of the bot will now instead a raise a partially validated flag that the bot code will look for when vital metadata is missing. It will not acknowledge the archive URL as valid, but it will not replace the archive URL on wiki.