[SERVER-11492] Upserts to config servers incorrectly set "n" to 0 in getlasterror. Created: 30/Oct/13 Updated: 11/Jul/16 Resolved: 09/Dec/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client, Sharding |
| Affects Version/s: | 2.5.3 |
| Fix Version/s: | 2.5.5 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | 26qa | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||||
| Operating System: | ALL | |||||||||||||||||
| Steps To Reproduce: | Set up a sharded cluster, and point a shell at a mongos instance.
|
|||||||||||||||||
| Participants: | ||||||||||||||||||
| Description |
|
The object returned by the getlasterror command on an upsert that converts to an insert should report n = 1. However, when the upsert is targeted via a mongos at a collection on a config server, it instead sets n = 0. This is an error. |
| Comments |
| Comment by Andy Schwerin [ 13/Feb/14 ] |
|
No, but not fixing it makes us hack auth instead. If the fix is hard we can |
| Comment by Spencer Brody (Inactive) [ 09/Dec/13 ] |
|
The problem turned out to be that SyncClusterConnection, before running any command will run that command with help:1 to determine its lock type. This would happen when running getLastError, which would cause the error on that connection to be reset, so when the real non-help form of getLastError was run it would return an empty default write concern result. The fix was to make it so that running GLE in help mode doesn't reset the last error stored for the connection. |
| Comment by Spencer Brody (Inactive) [ 09/Dec/13 ] |
|
https://github.com/mongodb/mongo/commit/11cda2f697157e3832bc09d842f8fc71d319a87d |
| Comment by Daniel Pasette (Inactive) [ 05/Dec/13 ] |
|
is this a regression? |