[SERVER-57708] ClientMetadata Parsing errors can leave ClientMetadataState decoration in invalid state Created: 15/Jun/21 Updated: 29/Oct/23 Resolved: 17/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.15, 4.4.7, 5.0.0-rc3, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | George Wangensteen | Assignee: | George Wangensteen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | post-rc0 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v5.0, v4.4, v4.2
|
||||||||
| Sprint: | Service Arch 2021-06-28 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 133 | ||||||||
| Description |
|
We decorate OperationContexts with a ClientMetadataState here; a ClientMetadataState is a struct containing actual Client metadata and a boolean indicating whether or not the metadata has been set for some particular opCtx. When we read the ClientMetadata for an opCtx here, we assume that if the boolean in the ClientMetadataState is set to "true", then the decoration must contain metadata (in fact, we invariant that this is the case). However, when we write the ClientMetadata for an opCtx, it's possible we leave it in a state that breaks this invariant (i.e. where the boolean is set to "true" but we don't actually provide any metadata to the decoration). For example, when we set the metadata decoration for an opCtx here, we write "true" to the boolean, but then check two conditions with uassert (one is inside the call to ClientMetadata::readFromMetadata) before actually writing the metadata for the decoration. If these uasserts are hit, the decoration will be left with the boolean set to "true" but no actual metadata set. This is a problem if anyone tries to read the metadata later; this can happen in, for example the HandleRequest::completeOperation hook run after the operation fails here where CurOp::completeAndLogOperation will attempt to read the metadata and may hit the aforementioned invariant in ClientMetadata::getForOperation. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 21/Jun/21 ] |
|
Author: {'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}Message: (cherry picked from commit cc883e8854849bfcd7e0f4c670dfc5fdbbaf7abe) |
| Comment by Githook User [ 21/Jun/21 ] |
|
Author: {'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}Message: (cherry picked from commit cc883e8854849bfcd7e0f4c670dfc5fdbbaf7abe) |
| Comment by Githook User [ 21/Jun/21 ] |
|
Author: {'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}Message: (cherry picked from commit cc883e8854849bfcd7e0f4c670dfc5fdbbaf7abe) |
| Comment by Githook User [ 17/Jun/21 ] |
|
Author: {'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}Message: |