The current secondary behavior is just to invalidate the secondary's metadata so that the next request to the secondary causes an in-memory refresh. Refreshes require contacting the shard primary, in case the primary is not up to date either and must refresh from the config servers.

A secondary that has the up to date metadata persisted, but hasn't serviced requests in a long while so the up to date metadata hasn't been loaded into memory, can get stuck when it receives a request while either there is no primary or the primary cannot be contacted. To alleviate this situation, we will proactive reload the in-memory cache on receipt of metadata updates. This is a performance improvement.