This came up at a meeting a while back, but I realized it was never materially written down anywhere.
Compact Block high-bandwidth processing can fall back to getdatas when the client belives a short id collision may have occurred (among a few other cases). In such cases, we are required to wait until we have verified the full block before we can respond to the getdata request (hence the few awkward ActivateBestChain calls in net_processing). However, in case we find the block to be invalid (or decide its actually not our best-chain-candidate due to some race receiving another block in parallel) we will simply leave the getdata unresponded to. This will result in us eventually getting disconnected for stalling.
It is important to note that, were an attacker able to generate a block which, when relayed, would cause getdata fallbacks on an invalid block, such an attacker would be able to cause massive disconnections across the network, especially targeting mining nodes or other nodes which receive blocks particularly fastly. I do not believe such creation is currently possible, but definitely could be bad if we did something dumb like fixing the nonce in the future.
During the meeting we discussed using the existing NOTFOUND message for block requests as well, which seemed to have some level of support (or a BLOCK_NOTFOUND or whathaveyou) and using that to allow peers to simply reject providing a block without being disconnected as a staller.
