[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:
Backports
Depends
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: SERVER-57708 Ensure ClientMetadata left in valid state after failed parsing

(cherry picked from commit cc883e8854849bfcd7e0f4c670dfc5fdbbaf7abe)
Branch: v4.2
https://github.com/mongodb/mongo/commit/f14d6857c9956ada53cb56d9ac37dca1e5c1e811

Comment by Githook User [ 21/Jun/21 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-57708 Ensure ClientMetadata left in valid state after failed parsing

(cherry picked from commit cc883e8854849bfcd7e0f4c670dfc5fdbbaf7abe)
Branch: v4.4
https://github.com/mongodb/mongo/commit/3eecc7dea04954d571e674a60076809f4f5386a9

Comment by Githook User [ 21/Jun/21 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-57708 Ensure ClientMetadata left in valid state after failed parsing

(cherry picked from commit cc883e8854849bfcd7e0f4c670dfc5fdbbaf7abe)
Branch: v5.0
https://github.com/mongodb/mongo/commit/c4e024785e827880f8da65e9659f497bb2608e32

Comment by Githook User [ 17/Jun/21 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-57708 Ensure ClientMetadata left in valid state after failed parsing
Branch: master
https://github.com/mongodb/mongo/commit/cc883e8854849bfcd7e0f4c670dfc5fdbbaf7abe

Generated at Thu Feb 08 05:42:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.