|
eddie.louie and I spent some time debugging this one together. The solution is to remove the Object.defineProperty() lines since they were unnecessary anyway (SERVER-23219 is already causing the "_mongo" property to be defined on the response object).
The idea behind the changes from SERVER-26298 (which introduced the Object.defineProperty(res.master, "_mongo", {value: this.liveNodes.master}) logic) was to make it so we didn't need to rely on the host and port when collecting diagnostics from a secondary with a different dbhash. We chose to mimic the changes from SERVER-23219 to add a "_mongo" property to the returned object representing the server connection used to make the request. The changes from SERVER-23219 had already made it so that any response from the server via Mongo.prototype.runCommand() will include the original connection as the "_mongo" property.
As to why this only fails when useBridge=true, SpiderMonkey apparently doesn't consider it an error to assign a non-configurable, non-writable property the same value as its current value via Object.defineProperty() when it is a C++ object. It does however correctly error when it is a plain-old JavaScript object:
(function() {
|
"use strict";
|
const obj = {};
|
Object.defineProperty(obj, "prop", {value: 1});
|
obj.prop = 2;
|
})();
|
throws a "TypeError: "prop" is read-only" error. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Writable_attribute
|