[JAVA-1081] CommandResult.getException not detecting duplicate key errors reported in errObjects field Created: 16/Jan/14 Updated: 31/Jul/14 Resolved: 30/Jan/14 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Command Operations, Error Handling |
| Affects Version/s: | 2.11.3 |
| Fix Version/s: | 2.12.0, 3.0.0 |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Andrei Nicusan | Assignee: | Jeffrey Yemin |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows Server 2008 R2 Enterprise, 64-bit, 144GB RAM, |
||
| Issue Links: |
|
||||||||||||||||
| Description |
|
The getException() method of the com.mongodb.CommandResult class does not cover all the cases in which a duplicate key error occurs. The main reason for this behavior is that it is assumed that the error code is contained as the value of the "code" key in the root JSON response object. Here's a response object that I get when issuing an "insert" command:
There is no "code" attribute in the root JSON object, therefore a WriteConcernException is thrown, instead of a more specialized MongoException.DuplicateKey one. Definitely, it is the case of a duplicate key error, but the getException (or the getError) method does not implement the best efforts to identify a duplicate key error. The changed structure of the response object (compared to the expected one) might be because of the fact that the original "insert" command was issued to a mongos process, not to a mongod process. Such an issue limits the driver API clients in finding the duplicate key errors with 100% accuracy, which leads to MongoException.DuplicateKey exception not being 100% leveraged in client code. |
| Comments |
| Comment by Jeffrey Yemin [ 27/Feb/14 ] | |||
|
Hi there, Would you mind testing the fix for this issue in 2.12.0-rc0, available either on github or Maven Central? Thanks, | |||
| Comment by Jeffrey Yemin [ 31/Jan/14 ] | |||
|
Makes total sense. I changed the title to reflect the scope of the fix. | |||
| Comment by John Gallagher [ 31/Jan/14 ] | |||
|
Sure. I commented here because the title mentions "all cases". I will open a new ticket. The new ticket is here: | |||
| Comment by Jeffrey Yemin [ 31/Jan/14 ] | |||
|
John, No, it will not cover that case. It only handles the errObjects field, as included in the description of this ticket. Would you mind filing a new bug so we can consider a different fix for it. The fix for the case described in the description of this issue is fairly clean and doesn't involve any string matching, so I want to leave it as is. Thanks, | |||
| Comment by John Gallagher [ 31/Jan/14 ] | |||
|
Does this cover "caused by" errors, if the cause is inserted via causedBy in assert_util.h? We are running mongo-java-driver 2.11.3_fs-b, which includes the basic patch for checking E11000 for a single err object. Example exception that should have been converted:
| |||
| Comment by Githook User [ 30/Jan/14 ] | |||
|
Author: {u'username': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}Message: | |||
| Comment by Githook User [ 22/Jan/14 ] | |||
|
Author: {u'username': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}Message: | |||
| Comment by Andrei Nicusan [ 17/Jan/14 ] | |||
|
Hi, Jeff. Thanks for looking into this. The version I'm using is 2.2.3. | |||
| Comment by Jeffrey Yemin [ 16/Jan/14 ] | |||
|
See https://github.com/mongodb/mongo-python-driver/blob/master/pymongo/mongo_client.py#L1031 for a strategy to fix this using the embedded errObjects array of documents. | |||
| Comment by Jeffrey Yemin [ 16/Jan/14 ] | |||
|
Hi Andrei, What version of mongos are you using? Regards, | |||
| Comment by Jeffrey Yemin [ 16/Jan/14 ] | |||
|
Pull request for this at https://github.com/foursquare/mongo-java-driver/commit/baac864595fc326f0a7430ba9bdaf6b4f7a23701. |