Blockchain fork – how is the orphan block problem solved in this case?

What if some of my peers (blue peers) have a chain like this?

... -> A -> B -> D  (main chain)
        \-> C

Another colleague (green colleague) and I have:

... -> A -> B -> D  (main chain)

A blue peer may get into this situation when at some point it connects to another node that takes block C as the main chain. Therefore, the blue peer received the given block C. However, their (Blue Peer) main chain was the one with the B block, so only B was propagated to me (and later D), and C was stored locally as a stale block. Their old chain.

Now imagine the following scenario:

1. First comes block E whose parent is C. The blue peer chain is:

... -> A -> B -> D  (main chain)
        \-> C -> E

In this case, the blue peer increases the old chain and does not propagate E because it is not part of the main chain.

2. Then comes block F whose parent is E. The blue peer chain is:

... -> A -> B -> D  
        \-> C -> E -> F (main chain)

In this case, the blue peer switches to the chain with F and propagates F (header message) to us since this is the new main chain.

The problem here is that when block F (header via header message) is received, it first validates the parent hash and since block E is unknown, it considers block F as orphan and rejects it. In this way we consider all future blocks as orphans and reject them. As a result, we remain completely isolated from the network (me and all my red colleagues). Even if you connect to another network peer now, the situation will remain the same. How is this problem solved?