[DRIVERS-2032] Clarify server pinning behavior and pausable pool workflow Created: 17/Jan/22 Updated: 16/Jan/23 |
|
| Status: | Backlog |
| Project: | Drivers |
| Component/s: | Server Selection |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Unknown |
| Reporter: | Dmitry Lukyanov (Inactive) | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Driver Changes: | Not Needed | ||||||||||||
| Quarter: | FY24Q2 | ||||||||||||
| Description |
SummaryThis is follow-up ticket for DRIVERS-1998. We need to clarify behavior if pausable pool exception and pinning server are involved. MotivationWho is the affected end user?Drivers How likely is it that this problem or use case will occur?It's always reproducible in sharded transaction where pinning server is involved. Steps:
The same behavior where we use previously selected server happens in cursors. We pass the server that has been selected in the initial operation into cursor and don't select any other server for internal cursor operations like GetMore or KillCursor (regardless wire protocol). Our SDAM spec doesn't consider this case. But CMAP spec implicitly assumes that any operation(regardless logic like pinning) will go through server selecting process. We should clarify what behavior is expected here. Is this issue urgent?no Is this ticket required by a downstream team?no Is this ticket only for tests?no Acceptance Criteria
|