cargo-deny doesn't update the local sparse index cache (even though it could), a deliberate decision to rely solely on cargo itself to mutate the cache so that any potential bug in cargo-deny won't negatively impact users in any way. It's up to cargo when it wants to update the cache, in this case I assume every user had a local lockfile and all versions for every crate were in the crate and src caches, so cargo didn't feel the need to update the index.

I suppose I could add an option to force fetch index updates (but not write them to disk for the aforementioned reason) but to be honest that's not a great idea since that's an individual HTTP request per unique crate name when 99.9% of the time it's not going to result in a change to the yanked status for any of the versions in your crate graph.

Personally, this kind of seems to me a good thing that your CI catches it, as it's clear exactly what crate and version was yanked, so it's a trivial command to fix and push that everyone will get once the changed is merged and pulled.

But if you think you want a force-index-fetch option so this never happens that's fine, it just won't be high priority for me since I have other stuff to do.