Background & Context
The JS Test, resharding_prohibited_commands.js utilizes the config.cache.collections collections in order to verify that the committing decision has been relayed to the recipient.
It does this because it assumes either it will find the cached collection document where the `reshardingFields.state` property will be 'committing' or one of the other state values.
However, unlike other collections, the internal `config.cache.collections` collection has no such consistency guarantees. So it's possible that in between an old document being deleted and the new one being inserted, that it will find nothing.
In the ShardServerCatalogCacheLoader, the function that handles the refreshes to the `config.cache.collections` collection will first delete and then insert a new document in the case of an epoch change.
Since Resharding utilizes epoc changes to invalidate the shard's cache of the collection information, there is a space of time between the delete and insertion of the document in the `config.cache.collections` collection, where the test can read an invalid state (no collection document).
The test therefore is making an invalid assumption about the consistency that the `config.cache.collections` collection actually adheres to.
Proposed Solution
A simple solution would be to update the usages of find queries (3 in total) in the `cache.config.collections` collection in this test to first check if the response is null (because it found no documents matching the query) before using the value.
Such as:
return res && res.reshardingFields.status === "comitting"
- is related to
-
SERVER-58917 Wait until donors/recipients are aware that coordinator has persisted decision before expecting successful collMod, createIndexes, and dropIndexes in resharding_prohibited_commands.js
-
- Closed
-