I guess this is the minimal step to unbreak the logic, but I'm not fond of what this is doing at all: the "key" for a skipped content really is the quadruple of hashes, some potentially null; not any single one of them.

At some point this logic should be adapted to use a proper key tuple instead of a single hash.

Yes indeed. The point of this proxy is not to be optimal in its detection, but to save some bandwidth in practice, so I think it's good enough this way

Well. If we consider the case of two different contents with an identical sha1_git, different other_hashes, and a size larger than the limit, in practice the current implementation of the filter would make one mask the other.

This is the edge of an edge case that shouldn't show up in practice, of course. But we should note it down and fix that eventually.