[SERVER-23222] Replset metadata is not attached to command response on the exception path Created: 18/Mar/16  Updated: 09/May/16  Resolved: 06/Apr/16

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

Type: Bug Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-23502 remove metadata hooks' dependency on ... Closed
Related
related to SERVER-24113 OplogFetcher getMore callback QueryRe... Closed
is related to SERVER-24088 oplog fetcher should retry on getMore... Closed
Operating System: ALL
Participants:

 Description   

Both ConfigServerMetadata and ReplSetMetadata are added to a command response in Command::run on the normal path:

https://github.com/mongodb/mongo/blob/ee5fbdd8540d93d2e0d6fa19ba9a5595bb1829cb/src/mongo/db/dbcommands.cpp#L1463-L1480

but the ReplSetMetadata is not added on the exception path (though ConfigServerMetadata is):

https://github.com/mongodb/mongo/blob/ee5fbdd8540d93d2e0d6fa19ba9a5595bb1829cb/src/mongo/db/dbcommands.cpp#L1324-L1342

(Since the config server opTime from a config itself is reported as part of ReplSetMetadata, the ReplSetMetadata should always be returned.)



 Comments   
Comment by Spencer Brody (Inactive) [ 04/Apr/16 ]

Yeah, I think that makes sense to me.

Comment by Esha Maharishi (Inactive) [ 04/Apr/16 ]

Good point, an easy workaround is to simply check if the ReplClientInfo on the txn has an opTime to report, and include it if so.

If we agree on that, I can do it as part of SERVER-23502.

Comment by Spencer Brody (Inactive) [ 04/Apr/16 ]

schwerin, I think that's probably true, I'm just not sure if I want to assert for sure that it's always true.

For instance with duplicate key inserts, the command fails but we still want to update the caller's optime. In that specific case I think it fails without throwing an exception, so the metadata is still attached, but there could be other commands that fail based on the state of the data and thus should be updating the caller's optime, and I don't know that they'll never fail via an exception. Also just in general it feels weird to have different behavior depending on if the command fails via returning with appendCommandStatus with a non-ok status vs failing via an exception.

Comment by Andy Schwerin [ 19/Mar/16 ]

Is this really a bug? In the exception case, you don't learn about any data, do you?

Generated at Thu Feb 08 04:02:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.