[SERVER-35180] Safeguard from setting operation session info values while in a direct client Created: 22/May/18 Updated: 08/Jan/24 Resolved: 09/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client, Shell |
| Affects Version/s: | 3.6.5, 4.0.0-rc4 |
| Fix Version/s: | 3.6.7, 4.0.2, 4.1.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Blake Oler |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||
| Steps To Reproduce: |
|
||||||||
| Sprint: | Sharding 2018-07-16, Sharding 2018-07-30, Sharding 2018-08-13 | ||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| Linked BF Score: | 0 | ||||||||
| Description |
|
Update: to solve a greater issue uncovered by this ticket, we will prevent any operation session info from being set inside a direct client. Since eval reuses its operation context for the commands it runs, if an eval is run inside a session and an inner command contains a different lsid, this invariant can be hit when parsing the inner command here, since the outer eval will have already placed the id of its session on the operation context. This doesn't fail for other commands as far as I can tell, only count. It may have something to do with the special handling of count inside dbdirectclient. Example stacktrace:
|
| Comments |
| Comment by Githook User [ 09/Aug/18 ] |
|
Author: {'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}Message: |
| Comment by Githook User [ 09/Aug/18 ] |
|
Author: {'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}Message: (cherry picked from commit 56059c0dba6db079798f67a0a4063c4c3921ddb8) |
| Comment by Githook User [ 02/Aug/18 ] |
|
Author: {'username': 'BlakeIsBlake', 'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com'}Message: (cherry picked from commit 56059c0dba6db079798f67a0a4063c4c3921ddb8) |
| Comment by Ian Whalen (Inactive) [ 01/Aug/18 ] |
|
ah, you're right, it looks like i misinterpreted "had one successful execution before your commit" as "started with your commit" - should have scrolled down further. sorry! |
| Comment by Blake Oler [ 01/Aug/18 ] |
|
After taking a cursory look ian.whalen, this failure is not related to my patch. Refer to BF-9863. |
| Comment by Ian Whalen (Inactive) [ 01/Aug/18 ] |
|
blake.oler will your next patch fix the regression introduced here? |
| Comment by Githook User [ 30/Jul/18 ] |
|
Author: {'username': 'BlakeIsBlake', 'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com'}Message: |
| Comment by Githook User [ 30/Jul/18 ] |
|
Author: {'username': 'BlakeIsBlake', 'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com'}Message: |
| Comment by Blake Oler [ 24/Jul/18 ] |
|
After talking to mira.carey@mongodb.com, we've decided that attempting to set any operation session info while inside a direct client is unwanted behavior. The solution here will be to throw if any of
are defined while the opCtx is in a direct client. |
| Comment by Gregory McKeon (Inactive) [ 04/Jun/18 ] |
|
Sending to sharding to triage, since they own sessions. |
| Comment by Bruce Lucas (Inactive) [ 23/May/18 ] |
|
Is this related to |