In order to serve a secondary read that went through a router, a secondary node must have a valid ownership metadata with a shard version that is aligned with the version that the router attached to the operation. That's how we validate that the operation was routed to the right place.

The protocol to install the ownership metadata on secondary nodes is the following one (skipping some minor details for the sake of clarity):

1.  The secondary node realizes that its ownership metadata is stale / is missing (e.g. because of a binary restart).
2. The secondary node asks the primary node to perform a refresh, which will hit the CSRS and then the primary node will write down the received chunks.
3. The secondary node will wait until the oplog entries associated with the writes of the chunks are locally replicated.
4. The secondary node will locally read the ownership information and install it in-memory.

Thus, in order to install the filtering metadata on a secondary node, this one must be able to see through replication an oplog entry that was caused by the refresh itself.  Note that this property is problematic for lagged secondary nodes: they will have to wait the replication lag the customer is experiencing before being able to install the ownership metadata and being able to serve operations.