-
Type:
Bug
-
Resolution: Won't Fix
-
Priority:
Major - P3
-
None
-
Affects Version/s: 7.0.0, 8.0.0-rc0
-
Component/s: None
-
Catalog and Routing
-
ALL
-
CAR Team 2024-05-13
-
10
-
2
Due to SERVER-80135, collection metadata refresh after a shard collection now occur asynchronously. This change should not impact tests, as it is correct to have nodes with unknown or cleared metadata.
If an operation is run in a shard with cleared metadata, at the time the metadata is checked locally on the shard, it will trigger a StaleConfig error. The service entry point of the shard will handle this error and install the correct metadata. Then, it will either locally retry the operation or fail with StaleConfig waiting for the router to retry the op.
However, if this error occurs in a FLE sharded collection, it is bubbled up to the router and not retried. In contrast, if the collection is not encrypted, it would have been retried.
Consequently, there is a lack of parity between retrievability transactions in sharded collections and FLE sharded collections.
- is related to
-
-
- Closed
-
-
SERVER-60369 [txnRetryCounter] Use txnRetryCounter on router to retry on some transient errors in a client transaction
-
- Backlog
-
- related to
-
-
- Open
-
-
-
- Closed
-