[SERVER-86074] investigate if $out, insert and create can return LockBusy instead of MovePrimaryInProgress for unsplittable collections Created: 01/Feb/24 Updated: 02/Feb/24 |
|
| Status: | Needs Scheduling |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Enrico Golfieri | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
After This causes the shardsvrCreateCollection (and therefore the caller) to fail with "LockBusy" in case a concurrent operation is in progress. Specifically for the movePrimary, a special error "movePrimaryInProgress" is thrown for this case by specific operation such as createIndex. Insert, $out and "create" used to return movePrimaryInProgress and now return LockBusy. The goal of this ticket is to investigate whether is ok to now return LockBusy or instead movePrimaryInProgress should be enforced for back-compatibility |