Here’s what the statistics page says:
2015-06-15 17:48:11 OK (200)
2015-06-15 17:48:10 HTTP Redirect (18 to go) (301)
2015-06-15 16:37:56 OK (200)
2015-06-15 16:37:52 HTTP Redirect (18 to go) (301)
2015-06-15 15:32:03 OK (200)
It’s been saying “18 to go” for a few days, and it still says it if I manually “insta-fetch,” though the timestamps get updated.
You’re seeing what I call a branched feed. They are the same feed, but one is a branch of the other. It’s what happens when a user changes the feed address of a feed that isn’t having any exceptions. So instead of forcing all users to switch, NewsBlur branches the feed and keeps a link back to the original.
Both feeds work, so what are you looking to fix? The 18 to go issue is that the blog keeps alternating between errors and 200 OK status codes.
Ah, I didn’t know about the “branched feed” behavior, so you can ignore that last post.
Returning to the original issue: It looks to me like the 200/OK happens after Newsblur follows the redirect, and that 200 resets the counter, so it never goes past 18 (really 19, like you said above).
To clarify: example.old sends a 301 redirect to example.new, and example.new would send a 200, as you’d expect.
Whatever the cause of the reset, it means none of these redirects are being made permanent.
Ok, I pushed out a fix for it. I moved it down to 10 bad fetches, and I now keep the history if there are *any* exceptions in it, resulting in a successful page change after 10 bad fetches among the past 25 fetches.
Thanks! That sounds like it’ll have the desired effect, although it doesn’t address the 18 vs. 19 to go bug or the logic of the checks… I’ll keep an eye on a few feeds and see how it goes