General Plan/Feature List about checker_mal HOT 2 CLOSED

just going to highlight this part because Im often confusing/double-guessing myself as to whether or not caching the last unapproved entry is necessary.

It is not necessary.

We can figure out what the last unapproved item was, by doing the set difference of all the IDs with the approved set.

If what was the last unapproved entry was denied, it no longer exists, so we don't have to check that far back. The next time we calculate the oldest unapproved ID, it'll be the next oldest unapproved entry, which is fine -- since the old one 404s now.

If what was the last unapproved entry was approved, the whole point of checking that as a 'page range' is that we'd find it, so we'd find it when we check the unapproved 'page range' ((-2) in mal-id-cache)'

from checker_mal.

Again, to dispute the commit message from then:

if the last entry was approved, theres a possibility
that the last entry is not found, since this uses
the last unapproved ID as the loop condition
to go back till when '-2' is the key
for unapproved entries.

at the point at which you're deciding what the last unapproved ID is, if that entry was approved, we're not aware of that -- its not the in the approved set of IDs

so, we assume its unapproved and go back that many pages, find it and mark it approved

next time, we dont go back that far, which is correct

from checker_mal.