[SERVER-79892] Inconsistent profiling output for inserts Created: 10/Aug/23  Updated: 11/Aug/23  Resolved: 10/Aug/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Wenbin Zhu Assignee: [DO NOT USE] Backlog - Storage Execution NAMER
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-79891 Inconsistent profiling output for ins... Backlog
Assigned Teams:
Storage Execution NAMER
Operating System: ALL
Participants:

 Description   

For the insert operation, the profiling output is currently inconsistent in some ways:

1) Inconsistency between inserts initiates from mongod v.s. inserts sent from mongos

When we do an insert directly from monogd, the profile entry in the <db>.system.profile collection will contain and entry with a field "command" like this:

    "command" : {
        "insert" : "coll",
        "lsid" : { ... },
        "$clusterTime" : { ... },
        "$db" : "test",
    },{}

Note that this does not include the actual documents inserted (which seems not desired), however if the insert command is sent from mongos, "command" field will include a subField "documents" that is an array of all the inserted documents.

The reason of the difference is two-folded:

a) For the similar reason described in SERVER-79442, for requests initiated from mongod, any field that are marked as 'supports_doc_sequence' (such as the "documents" field in the insert command, the "updates" field in the update command and the "deletes" field in the delete command) will only be present in the OpMsg::sequences vector, but not in OpMsg::body, while for requests sent from mongos, requests are serialized in a way such that all fields are in OpMsg::body.

b) For every command handled by mongod, curOpCommandSetup() will first be called to set basic command info in CurOp,  where it calls setOpDescription_inlock() to set opDescription using OpMsg::body, and this is basically what's printed in the "command" field of the profile entry. However, the problem is that unlike update and delete command where they unroll each update/delete op and overwrite the opDescription with the individual update/delete op, insert does not do that. Combined with a), inserts initiated from mongod will lose the "documents" field in the profile entry.

 

2) Inconsistency between inserts v.s. updates/deletes

From the above example profile output, we can see that insert command includes some request-level fields like $clusterTime,{} $db,{} txnNumber, etc. However due to aforementioned reason b), update and delete commands will overwrite the opDescription with individual update/delete op and so will not include those request-level fields. And we seem to be relying on this to for JS tests because when I did a one-line change to make inserts also overwrite opDescription with the inserted documents, I saw a bunch of tests failed because they expect the request level fields being present in the insert command profile output. I think ultimately insert/update/delete should have consistent profile entry format, but I'm not sure whether we want to fix insert or fix update/delete. If I have to guess, we probably want to have the request-level fields to be present in update/delete as well.


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