[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: |
|
||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Both ConfigServerMetadata and ReplSetMetadata are added to a command response in Command::run on the normal path: but the ReplSetMetadata is not added on the exception path (though ConfigServerMetadata is): (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 |
| 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? |