[SERVER-48308] Avoid leaking exceptions in establishCursors cleanup callback Created: 19/May/20 Updated: 29/Oct/23 Resolved: 20/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 4.5.1, 4.4.0-rc4 |
| Fix Version/s: | 4.4.0-rc7, 4.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ian Boros | Assignee: | Nicholas Zolnierz |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | qopt-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||||||||||
| Sprint: | Query 2020-06-01 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
This uassert can trigger when the task executor is shutting down. The exception will bubble up, through this function marked noexcept. I would suggest getting rid of the uassert and instead log a message when args.status is not OK. It would also be good to add some documentation about the rules of callbacks and exception throwing. My guess is that callback functions passed to TaskExecutor::scheduleWork() should never throw but I don't see any warnings about it in task_executor.h. |
| Comments |
| Comment by Githook User [ 21/May/20 ] |
|
Author: {'name': 'Nick Zolnierz', 'email': 'nicholas.zolnierz@mongodb.com', 'username': 'nzolnierzmdb'}Message: (cherry picked from commit 617bcd621bd715aa52ed7a74c5dbd3d6689aa272) |
| Comment by Githook User [ 20/May/20 ] |
|
Author: {'name': 'Nick Zolnierz', 'email': 'nicholas.zolnierz@mongodb.com', 'username': 'nzolnierzmdb'}Message: |
| Comment by Nicholas Zolnierz [ 20/May/20 ] |
|
Thanks ian.boros, seems reasonable to change the uassert to a warning instead. My original thought of explicitly handling the shutdown error code isn't needed, since any non-OK status would indicate that the cleanup failed (or shouldn't proceed). |
| Comment by Ian Boros [ 19/May/20 ] |
|
CC nicholas.zolnierz. I think we can fix this with suggestion in the ticket description but you'll probably know for sure. |