[SERVER-34248] Investigate why function_string_representation.js started failing Created: 02/Apr/18 Updated: 29/Oct/23 Resolved: 11/Jun/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | 3.7.3 |
| Fix Version/s: | 3.6.9, 4.0.0, 4.1.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Robert Guo (Inactive) | Assignee: | Robert Guo (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | tig-skip-pointing | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||||||||||
| Sprint: | TIG 2018-04-09, TIG 2018-05-21, TIG 2018-06-04, TIG 2018-06-18 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 68 | ||||||||||||||||
| Comments |
| Comment by Githook User [ 20/Sep/18 ] | ||||||||||||||||||||||||||||||||
|
Author: {'name': 'Robert Guo', 'email': 'robert.guo@10gen.com', 'username': 'guoyr'}Message: (cherry picked from commit 59235c563bd0498fc796620169cfedc1b2307350) | ||||||||||||||||||||||||||||||||
| Comment by Githook User [ 11/Jun/18 ] | ||||||||||||||||||||||||||||||||
|
Author: {'username': 'guoyr', 'name': 'Robert Guo', 'email': 'robert.guo@10gen.com'}Message: (cherry picked from commit 59235c563bd0498fc796620169cfedc1b2307350) | ||||||||||||||||||||||||||||||||
| Comment by Githook User [ 11/Jun/18 ] | ||||||||||||||||||||||||||||||||
|
Author: {'username': 'guoyr', 'name': 'Robert Guo', 'email': 'robert.guo@10gen.com'}Message: | ||||||||||||||||||||||||||||||||
| Comment by Robert Guo (Inactive) [ 04/Jun/18 ] | ||||||||||||||||||||||||||||||||
|
The error comes from this line to check if the collection is empty . When the config server uses an existing connection from its DBConn pool, regardless of whether it's to the primary or the secondary of a shard, the connection does not see the output of mapreduce, but when we create a new connection to one of the shard nodes, the new connection will take a new enough of a snapshot to see some or all of the data from the mapreduce call, causing the above line to error. Applying the following one-line patch will allow the config server to establish a connection to the shard secondary and store it in the conn pool. So in the code linked above when the configsvr tries to contact the shard secondary again, the test passes. Note that we're assuming the same secondary is contacted, which indeed seems to be the case.
I didn't dig further into why the result of mapreduce was not visible to established connections and only new ones. | ||||||||||||||||||||||||||||||||
| Comment by Githook User [ 02/Apr/18 ] | ||||||||||||||||||||||||||||||||
|
Author: {'email': 'robert.guo@10gen.com', 'name': 'Robert Guo', 'username': 'guoyr'}Message: | ||||||||||||||||||||||||||||||||
| Comment by Githook User [ 02/Apr/18 ] | ||||||||||||||||||||||||||||||||
|
Author: {'email': 'robert.guo@10gen.com', 'name': 'Robert Guo', 'username': 'guoyr'}Message: |