That would add at least a round-trip latency on every true miss that hits eqiad/esams/ulsfo (new or just purged page), won't it?

On a true miss, yes, it would add a codfw<->eqiad round-trip. That's ~35ms though, which may be hard for MW to beat on average. True miss should be rare though, except when a backend cache has been wiped, in which case we'd rather spam eqiad<->codfw to side-reload the cache than spam the applayer.

This wouldn't apply to passes from hit-for-pass, though. It also shouldn't apply to a normal page expiry within the grace window. I'm unsure about purges, probably depends whether we use 'softpurge' or not (which allows the page contents to still be in grace briefly - seems like a fine choice given purging isn't synchronous anyways, if we can keep the grace window small).

Oh, re-reading your question, you mentioned specific DCs. In the current layout where only eqiad is "primary", the side-checks from eqiad to codfw would only happen for requests that initially enter through esams or eqiad. ulsfo flows through codfw on its way to eqiad.

Of course, if MW can beat an eqiad<->codfw trip for the same page... we could look at other ways to structure this so it doesn't kick in all the time. Perhaps trigger it only in the first X minutes after a fresh varnishd restart, or only trigger it when we run out of connection parallelism limit to the real mediawiki backend?