[SERVER-83709] Make kill_cursors_in_transaction.js resilient to LockTimeout Created: 29/Nov/23 Updated: 30/Nov/23 Resolved: 30/Nov/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.3.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Damian Wasilewicz | Assignee: | Damian Wasilewicz |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Execution Team 2023-12-11 | ||||
| Participants: | |||||
| Linked BF Score: | 5 | ||||
| Description |
|
Currently kill_cursors_in_transaction.js tries to test that killCursors does not block behind a pending MODE_X lock issued from a drop command. However, it is possible that ticket exhaustion may occur and that the killcursor command can fail with an "Unable to acquire ticket with mode '2' due to detected lock conflict", due to a detected deadlock. Since this is allowed behavior and killCursors is not considered to be blocked in this case, we should check if the error Msg is LockTimeout and rollback the transaction. This is done to address the issue in BF-30628. |
| Comments |
| Comment by Githook User [ 30/Nov/23 ] |
|
Author: {'name': 'Damian Wasilewicz', 'email': '33820523+DamianWasilewicz@users.noreply.github.com', 'username': 'DamianWasilewicz'}Message: |