[SERVER-73107] [v4.4] Audit usage of default constructed WriteConcernOptions() in sharding catalog manipulation Created: 19/Jan/23  Updated: 15/Jun/23  Resolved: 15/Jun/23

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Allison Easton
Resolution: Done Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-73106 [v4.4] Chunk migration attempts to wa... Closed
is related to SERVER-78116 [v4.4] Chunk migration still attempts... Closed
Assigned Teams:
Sharding EMEA
Sprint: Sharding EMEA 2023-05-29, Sharding EMEA 2023-06-12, Sharding EMEA 2023-06-26
Participants:

 Description   

As observed in SERVER-73106, the meaning of the default-constructed WriteConcernOptions() is dependent on the presence of getLastErrorDefaults in the replica set config. It may be worthwhile to audit the usages of the default-constructed WriteConcernOptions() in other areas of the sharding codebase:

Explicitly specifying a {w: 1} write concern for internal operations will prevent getLastErrorDefaults in the replica set config from an effect.

const WriteConcernOptions kNoWaitWriteConcern{1, WriteConcernOptions::SyncMode::UNSET, Seconds(0)};



 Comments   
Comment by Allison Easton [ 15/Jun/23 ]

I have investigated/tested the different usages of WriteConcernOptions() in the sharding code in 4.4. The only one that has given me issues is the one in the migration destination manager when persisting the range deletion task.

What I have discovered is that the issue is not WriteConcernOptions() being overridden by getLastErrorDefaults - WriteConcernOptions() is interpreted as default but it is also interpreted as being supplied by the client which means it is being honored.

The problem with the usage in the migration destination manager is that it is using the persistent task store. The persistent task store sends its commands without any write concern at all and then waits for write concern at the end. This means that the write concern is treated as unset, allowing it to be overridden by getLastErrorDefaults.

This means that the fix from SERVER-73106 is insufficient. In order to have the write concern not be overridden by getLastErrorDefaults, we need to attach WriteConcernOptions() to the operations done in the persistent task store.

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