What is the purpose/benefit of the binfmt image cache?

[MichaIng]

I just recognized that, on a GitHub-hosted runner, this action takes significantly longer (well, in relative terms, like 8s vs 3s) when a valid cache is restored. Reading through the comments in #130 and again the logs it totally makes sense, since it pulls a new image in any case (to compare with the cached one), so restoring the cache, comparing the pulled image, saving back to cache, are additional steps coming on top of everything which happens when the cache is disabled.

So do I understand it right that the cache is solely meant to help against failures due to temporary network errors (at runner or Docker registry), and not at all to speed things up or reduce traffic?

In that case it does not seem to fully fix #166 either, as that user still needs to wait long for the docker pull with slow network, which is attempted in any case, just allows it to fail? Not sure whether there is a good way to not pull the full image from Docker registry, but a hash to compare only? That had the potential to turn the cache into a speedup and resource savings option, instead of more like an optional fallback that it is now.