Each write operation must lock the collection on which it's working on. To do this, the description of the collection is required to determine if the collection is sharded or not.

When getting the collection description, if the current metadata is not available, the function throws a StaleConfigInfo error attaching an ignored received shard version.

After the write operation is closed, since a StaleConfigInfo error has been raised, the shard manages a shard version mismatch (ignored vs local shard version) and then triggers a full or partial refresh of the catalog cache to recover the shard version.

This is inefficient. The context of the write operation could embed a concrete shard version, which must be used when the StaleConfigInfo error is thrown, avoiding to recover the shard version from the CSRS.