Currently, if a config stepdown occurs after the database has been written to the sharding catalog but before the config sends _flushDatabaseCacheUpdates to the primary shard, a _configsvrCreateDatabase retry will see that the database already exists in the sharding catalog, and so returns early without running _flushDatabaseCacheUpdates.

As a result, a database can be created even though the primary shard's filtering metadata for the database is "unknown." This is not incorrect, but is not optimal as described here

Making _configsvrCreateDatabase send _flushDatabaseCacheUpdates even if the database already exists is not a perfect solution, since if the router does not retry (e.g., because the router crashed) or exhausts its retries (e.g., due to repeated network errors), this issue can still occur. However, this solution will at least prevent the BF from happening on Evergreen. A correct solution would require a larger design change to how the sharding catalog is kept in sync between the config server and shards.