[SERVER-45739] Make resubmitRangeDeletionsOnStepUp exception-safe Created: 24/Jan/20  Updated: 29/Oct/23  Resolved: 04/Mar/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.4.0-rc0, 4.7.0

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

Issue Links:
Backports
Related
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4
Sprint: Sharding 2020-02-24, Sharding 2020-03-09
Participants:
Linked BF Score: 21

 Description   

migrationutil::submitPendingDeletions can throw (e.g., if PersistentTaskStore::forEach throws, which can happen at least if a range deletion doc cannot be parsed), which will cause resubmitRangeDeletionsOnStepUp to terminate the server since it would be an unhandled exception.

At the very least, we should add a try/catch in resubmitRangeDeletionsOnStepUp.



 Comments   
Comment by Githook User [ 09/Mar/20 ]

Author:

{'username': 'alextaskov', 'name': 'Alex Taskov', 'email': 'alex.taskov@mongodb.com'}

Message: SERVER-45739 Make resubmitRangeDeletionsOnStepUp exception-safe

(cherry picked from commit 88c9f8c1c267e2b8068dc5e0c0018ada71642834)
Branch: v4.4
https://github.com/mongodb/mongo/commit/6596d5a40adfe367cb408c09f90327ff64badaec

Comment by Kelsey Schubert [ 06/Mar/20 ]

This needs to be backported to 4.4, since the fixversion was 4.3 required, unless I'm missing something.

Comment by Githook User [ 04/Mar/20 ]

Author:

{'username': 'alextaskov', 'name': 'Alex Taskov', 'email': 'alex.taskov@mongodb.com'}

Message: SERVER-45739 Make resubmitRangeDeletionsOnStepUp exception-safe
Branch: master
https://github.com/mongodb/mongo/commit/88c9f8c1c267e2b8068dc5e0c0018ada71642834

Comment by Esha Maharishi (Inactive) [ 24/Jan/20 ]

Marking as related to BF-15914, since that's where I discovered this issue.

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