[SERVER-31056] Remove all usages of the default constructor of ScopedCollectionMetadata outside of MetadataManager Created: 12/Sep/17  Updated: 30/Oct/23  Resolved: 06/Dec/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.5.13
Fix Version/s: 3.6.1, 3.7.1

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Kaloian Manassiev
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-32198 Missing collection metadata on the sh... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6
Sprint: Sharding 2017-12-04, Sharding 2017-12-18
Participants:

 Description   

The ScopedCollectionMetadata object is supposed to only be created by the MetadataManager since only it knows definitively what the current metadata for the collection is. Currently there are call sites which create ScopedCollectionMetadata using the default constructor, which makes it difficult to ensure correctness in one place.

Because of this we should remove all usages of the default constructor outside of MetadataManager.



 Comments   
Comment by Githook User [ 08/Dec/17 ]

Author:

{'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}

Message: SERVER-31056 Remove all usages of the default constructor of ScopedCollectionMetadata outside of MetadataManager

Contains the combined backport of multiple commits listed below.

SERVER-31056 Cleanup MetadataManager and CollectionMetadata

No functional changes, only cleanup to improve readability.

  • Removes unused code
  • Improve comments
  • Hide functionality, which doesn't need to be public

(cherry picked from commit 88fa04b3791d1e53444601432677bb0cf86dc293)

SERVER-31056 Make CollectionMetadata immutable

It shouldn't contain state internal to the metadata manager.

(cherry picked from commit b732abe6b1295740c3a5799c5903f84cd1857347)

SERVER-31056 Remove usages of ScopedCollectionMetadata default constructor

(cherry picked from commit 95e95613412c33b52bb8a514751550c2447526d4)

SERVER-31056 Remove all usages of the ScopedCollectionMetadata default constructor

With this commit, only the MetadataManager is allowed to instantiate
empty ScopedCollectionMetadata objects.

(cherry picked from commit 762765c80b005375c3c3b893772c7284271598ea)

SERVER-31056 Remove the KeyRange type from non-test code

(cherry picked from commit d5be73dbe4d28211994746dc1f5b47fb840ccdbd)

SERVER-31056 Do not uassert with code StaleConfig

The StaleConfig error code is interpreted in a special way and it
requires the presence of StaleConfigException. Because of this we should
never uassert with it directly.

(cherry picked from commit 4fcaef90b1ca91b4806bace87da568565d5633c9)
Branch: v3.6
https://github.com/mongodb/mongo/commit/5d48397bfcd56bea4afabe9fb1187416afd591e5

Comment by Kaloian Manassiev [ 06/Dec/17 ]

Due to the extent of the preparation changes which were necessary in order to fix this bug, I am retitling it to mean "remove all usages of the default constructor of ScopedCollectionMetadata" and moving the final fix to differentiate between unsharded and "metadata not known" to SERVER-32198.

Comment by Githook User [ 06/Dec/17 ]

Author:

{'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-31056 Do not uassert with code StaleConfig

The StaleConfig error code is interpreted in a special way and it
requires the presence of StaleConfigException. Because of this we should
never uassert with it directly.
Branch: master
https://github.com/mongodb/mongo/commit/4fcaef90b1ca91b4806bace87da568565d5633c9

Comment by Githook User [ 06/Dec/17 ]

Author:

{'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-31056 Remove the KeyRange type from non-test code
Branch: master
https://github.com/mongodb/mongo/commit/d5be73dbe4d28211994746dc1f5b47fb840ccdbd

Comment by Githook User [ 05/Dec/17 ]

Author:

{'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev'}

Message: SERVER-31056 Remove all usages of the ScopedCollectionMetadata default constructor

With this commit, only the MetadataManager is allowed to instantiate
empty ScopedCollectionMetadata objects.
Branch: master
https://github.com/mongodb/mongo/commit/762765c80b005375c3c3b893772c7284271598ea

Comment by Githook User [ 04/Dec/17 ]

Author:

{'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev'}

Message: SERVER-31056 Remove usages of ScopedCollectionMetadata default constructor
Branch: master
https://github.com/mongodb/mongo/commit/95e95613412c33b52bb8a514751550c2447526d4

Comment by Githook User [ 29/Nov/17 ]

Author:

{'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-31056 Make CollectionMetadata immutable

It shouldn't contain state internal to the metadata manager.
Branch: master
https://github.com/mongodb/mongo/commit/b732abe6b1295740c3a5799c5903f84cd1857347

Comment by Githook User [ 29/Nov/17 ]

Author:

{'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-31056 Cleanup MetadataManager and CollectionMetadata

No functional changes, only cleanup to improve readability.

Comment by Spencer Brody (Inactive) [ 22/Nov/17 ]

If this is easy to do, then it'd be nice to do sooner and backport to 3.6 so changestreams can benefit from it in 3.6, rather than waiting and doing it as part of the larger collection lifecycle work.

Comment by Kaloian Manassiev [ 22/Nov/17 ]

This is not difficult to do. We can just make the MetadataManager have a state, which indicates "I don't know what's the metadata", which would always fail the shard version check.

Comment by Andy Schwerin [ 22/Nov/17 ]

I think we should consider this along with driving "shard collection" on the shard that owns the unsharded collection in order to make the routing table maintenance protocols more robust. Moving this back to "Needs Triage" to see if this could be done as part of collection lifecycle improvements or as a one-off during 3.7 development, perhaps with back port to 3.6.

Comment by Spencer Brody (Inactive) [ 22/Nov/17 ]

Note that linked ticket SERVER-24960 has a jstests that repros the issue.

Comment by Spencer Brody (Inactive) [ 22/Nov/17 ]

This issue also affects changeStreams.

Comment by Dianna Hohensee (Inactive) [ 14/Nov/17 ]

This can further occur on a secondary via the oplog when metadata changes reach it. Both entering the critical section and finishing a metadata refresh will persist changes that the secondary will notice in its oplog and prompt clearing of the metadata, leaving it in the same susceptible position noted in the ticket description.

This can happen as of SERVER-31275's commit.

Generated at Thu Feb 08 04:25:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.