[SERVER-67815] FindCommand sets both the nss and uuid on NamespaceStringOrUUID Created: 06/Jul/22  Updated: 29/Oct/23  Resolved: 22/May/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0

Type: Task Priority: Minor - P4
Reporter: Janna Golden Assignee: Justin Seyster
Resolution: Fixed Votes: 0
Labels: neweng, quick-tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Backwards Compatibility: Fully Compatible
Sprint: QO 2022-07-25, QO 2022-08-08, QO 2022-08-22, QO 2022-09-05, QO 2022-09-19, QO 2022-10-03, QE 2022-10-17, QE 2022-11-14, QE 2022-11-28, QE 2022-12-12, QE 2022-12-26, QE 2023-01-09
Participants:

 Description   

A NamespaceStringOrUUID object should only ever hold either a NamespaceString object or a DatabaseName + UUID. Previously, this was enforced because the constructors would only take one or the other, and there were no setters. However, a method NamespaceStringOrUUID::setNss() was added in order to override the namespace for find commands, making it possible to set both the nss and uuid/db name fields. This looks to be used in two places in the find command path - one of these places sets the nss field when the uuid field is already set. There are a number of places that the server relies on the fact that only one of the uuid or nss is set on a NamespaceStringOrUUID object.

I think we should either:

  • Remove NamespaceStringOrUUID::setNss() and reconstruct a NamespaceStringOrUUID object instead
  • Change NamespaceStringOrUUID::setNss() to also unset the uuid/db name


 Comments   
Comment by Matt Broadstone [ 22/May/23 ]

Fixed in SERVER-77228

Comment by Justin Seyster [ 18/Feb/23 ]

Quick update on this: replacing the value in FindCommandRequest::nssOrUUID as originally suggested seems like it should be viable and also improve the code by better enforcing an invariant.

While testing the change, I encountered a failing jstest that makes me think SBE might be relying on the incorrect behavior of storing both a NamespaceString and UUID. That has the potential to be a bug, so I'm going to continue to investigate at the next opportunity.

Generated at Thu Feb 08 06:09:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.