There are three ways in which an entry URL may change:

1. The entry item’s link in the feed changed, and the old link now redirects

   Previously, Pushl would try retrieving the old URL, would get redirected to the new URL, and then would only send updates for any target URLs which changed, coming from the new URL. It would also see the new URL as a separate entry and send out pings from it. At best, this meant that there would be duplicated pings from the old and new URLs.

   Now, it sees that the source URL has changed and re-sends all of the old pings from the old URL, which lets the endpoint know that the URL has changed and should be updated. (It also sends a fresh set of pings from the new URL, which will at least theoretically be ignored by the endpoint, if it’s implemented correctly.)

2. The entry item’s link in the feed changed, and the old link now generates an error

   This path hasn’t changed at all; Pushl saw the old URL as a deletion, and the new one as an addition, and either way would send out pings for all targets from both URLs.

3. The feed linked to it via a redirection URL (such as a short link or a tracking link), and the redirection changed

   Previously, Pushl would not see this as as change at all in the entry, and would not send out any updates at all for old targets. This causes all sorts of potential failures not worth enumerating.

   Now, it sees that the destination changed, and re-sends all pings from the old target URL, telling the endpoint to update them.

   However, this has now introduced a bug which I didn’t realize until writing up this explanation: it only works if the old redirected URL also redirects to the new entry URL, in which case it behaves like case 1 above. If the old URL now errors, this will appear as a deletion to the endpoint, and all of the mentions go away – and Pushl won’t ever try to re-send them.

   So, I’ve already made a bugfix (which will go out in the next Pushl release, whenever that is) where the pings are always sent from the original URL in the feed. This way, it’s up to the endpoint to see that the redirection updated. This puts the onus on the endpoint to be able to track changes in redirections in the source URL, or always use the source URL verbatim even if it’s a redirection. Either way, Pushl is trying its hardest to do the right thing in a tricky situation.

   Update: I rolled back that bugfix, because it had the much worse effect of breaking rel="canonical". A better solution would be to re-send the old pings from the old URL instead. Which is now implemented and tested working.

In an ideal world, case 3 simply wouldn’t happen, but unfortunately, a lot of feeds do this for various reasons. Feedburner is particularly egregious about it, but a lot of blogging platforms do it naturally; Tumblr, for example. And, heck, it’s easy to configure Publ to do that too (and it always does this for unauthorized posts, as part of the privacy model).

Anyway. Consider this fix my day 1 effort for the IndieWeb 2019 Challenge.