-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 8.1.0-rc0, 7.0.14, 8.0.0
-
Component/s: Sharding
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
v8.0, v7.0
-
-
CAR Team 2024-10-28, CAR Team 2024-11-11
-
0
-
1
SERVER-84723 added extra validations to have the guarantee that any operation on unsharded collections with atClusterTime or inside a transaction were done for the same incarnation of the collection. In practice, this was done by asserting that the collection catalog which was stashed is the same that the one present in the latest catalog.
This had an unintended consequence, during a rollback, a new collection catalog is installed, so, considering the intended check internally is comparing collection pointers, if an operation with a specific atClusterTime comes in after the rollback, and the minimum visible timestamp is higher, then the collection is opened (as in, recovered from Wired Tiger), which makes the validation to fail, because the opened collection will be seen as different than the one in the latest catalog.
From a user perspective, this might cause some reads with atClusterTime to fail after a rollback, or, a resharding operation to fail.
To ensure the same guarantee but being less strict, we could try to compare the collection catalog UUID's, if they're the same, then we can assume they are the same incarnation of the collection.
- is caused by
-
SERVER-84723 Sharded multi-document transactions can observe partial effects of concurrent DDL operations
- Closed