User talk:DYKToolsBot/BRFA 2 Draft

Edge cases

You should probably be aware of the various edge cases covered by TFA Protector bot (some discussed here, like redirects). You shouldn't need to have to restore protection later...in what case were you thinking of that?

I kind of wonder whether it makes sense to just incorporate this into TFA Protector bot, which already has pretty robust code for applying move protection. Or at the very least copy/fork the code. Legoktm (talk) 21:27, 20 February 2023 (UTC)

Thanks for the comment; I'll take a look. -- RoySmith (talk) 22:24, 20 February 2023 (UTC)

Maybe I don't need to save state at all?

I'm slowly coming to the conclusion that there's no need to maintain my own JSON database. All the state about what I need is already contained in the protection log. Just get a list of all the page protections performed by DYKToolsBot in the past 8 days; if any of those pages are no longer on the main page of any of the queues, they need to be unprotected. -- RoySmith (talk) 17:44, 21 February 2023 (UTC)

Can you clarify why things need to be unprotected in the first place? Why can't you just set the expiry to the correct length of time? Legoktm (talk) 21:43, 21 February 2023 (UTC)

The problem is that hooks get moved around even after they're put on a queue. In theory, they've been reviewed (twice three times) before hitting a queue so they really should be good to go at that point. In practice, people find problems in the queues on a depressingly regular basis. So the hook that got taken off the queue needs to get unprotected, and the one that replaced it needs to get protected. Sometimes people will just swap two hooks between queues; in that case, both still need to be protected, but the expiration times would change for both. Also (fairly rare, but we had a case just a week or two ago), the bot that updates the main page fails so hooks stay on the main page longer than expected. Sometimes hooks get pulled even after they hit the front page because somebody reports a serious problem at WP:ERRORS; sometimes we replace it with a new one, sometimes we just let the current hook set run with one less hook. And then there's the mess when the queue schedule changes and any pre-computed expiriations would now be wrong.

So I think the best thing is to not try to predict expiration times. You could try to optimize by doing a prediction, but you'd still need to check for all these weird edge cases and deal with them. It's easier (and thus less error-prone) to indef protect and re-evaluate every hook on every run. -- RoySmith (talk) 22:04, 21 February 2023 (UTC)