Since you have a BeaconState in scope here, I'd suggest doing state.validators().get(proposer_index as usize).map(|v| v.pubkey) rather than hitting the pubkey cache.

There can be some lock contention on the validator pubkey cache at times. There's also something very definite about saying "this validator doesn't exist in the state of the block they're proposing". You could even return an error in that case, I don't see how any block could be valid if the proposer index isn't in the validator registry. I would only do that if there's a benefit in dropping the Option around the pubkey, otherwise we might as well just leave it a warning and have one less way that block proposal can fail.

Ok used this state to get the pubkey here: ac15207

I've left the Option because dropping it doesn't gain us anything, but that's a good point, if the validator isn't in the state I too have no idea how it could propose. Seemed more like a possibility when I was using the cache 😂

From what I can see this function is always a noop. Is it here for future use?

Yes! In the fallback functionality in #3134, this populates a cache

So it'll either noop when getting a blinded block from a relay (no way to cache the payload) or it will cache when falling back to a local EE (have to cache the fully payload and return a blinded payload becaues the VC expects a blinded payload from this endpoint)