Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Done
Priority: Minor - P4
Fix Version/s: None
Affects Version/s: None
Component/s: None
Labels:
None

Assigned Teams:

Cluster Scalability
Backwards Compatibility:
Fully Compatible
Linked BF Score:
200
CAR Domain/s:
None

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

Estimated Weeks:
0

Audit places where cluster scalability code uses "opCtx->setAlwaysInterruptAtStepDownOrUp_UNSAFE();" to make sure that it is really "safe" to call. The motivation for this check came from discovering a location where this call turned out to be unsafe, preventing a command from being interrupted as expected during stepDown(see SERVER-104494 for more details).

is related to

SERVER-104258 Resharding Can Hang If Recipient Fails During ShardsvrReshardRecipientClone

Backlog

SERVER-104494 Resharding can hang if recipient steps down during ShardsvrReshardRecipientClone

Backlog

SERVER-105181 Replace uses of setAlwaysInterruptAtStepUpStepDown

Open

SERVER-66353 Add documentation of concurrency rules for OperationContext::setAlwaysInterruptAtStepDownOrUp

Closed

Assignee:: Brett Nawrocki
Reporter:: Kruti Shah
Participants:: Brett Nawrocki, Kruti Shah, TPM Jira Automations Bot
Votes:: 0 Vote for this issue
Watchers:: 11 Start watching this issue

Due:: 07/Aug/25
Created:: May 19 2025 03:28:48 PM UTC
Updated:: Aug 06 2025 05:18:34 PM UTC
Resolved:: Aug 05 2025 08:34:58 PM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates