<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 04:31:00 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[SERVER-32691] Create passthrough for w=&quot;majority&quot; with 2-node replica set to address lost test coverage</title>
                <link>https://jira.mongodb.org/browse/SERVER-32691</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;The changes in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-31670&quot; title=&quot;Change replica set fixture used by replica_sets_jscore_passthrough to make its secondary have zero votes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-31670&quot;&gt;&lt;del&gt;SERVER-31670&lt;/del&gt;&lt;/a&gt; made suites using the &lt;tt&gt;ReplicaSetFixture&lt;/tt&gt; have non-voting secondaries by default unless &lt;tt&gt;voting_secondaries=true&lt;/tt&gt; or &lt;tt&gt;all_nodes_electable=True&lt;/tt&gt;. There are test suites for readConcern={level: &quot;majority&quot;} that were incidentally testing w=&quot;majority&quot; writeConcern. However, none of these test suites actually verified that the secondary in a 2-node replica set had applied the write immediately after the client performed a w=&quot;majority&quot; write.&lt;/p&gt;

&lt;p&gt;We should add a new &lt;tt&gt;write_concern_majority_passthrough.yml&lt;/tt&gt; test suite that uses both (1) the &lt;tt&gt;set_read_and_write_concerns.js&lt;/tt&gt; override with w=&quot;majority&quot; and readConcern={level: &quot;level} and (2) the &lt;tt&gt;set_read_preference_secondary.js&lt;/tt&gt; override. It should be backported to the 3.2, 3.4, and 3.6 branches and run anywhere we already run an of &lt;tt&gt;aggregation_read_concern_majority_passthrough.yml&lt;/tt&gt;, &lt;tt&gt;read_concern_linearizable_passthrough.yml&lt;/tt&gt;, and &lt;tt&gt;read_concern_majority_passthrough.yml&lt;/tt&gt; test suites.&lt;/p&gt;

&lt;hr /&gt;

&lt;h6&gt;&lt;a name=&quot;Originalsummary&quot;&gt;&lt;/a&gt;Original summary&lt;/h6&gt;
&lt;p&gt;Passthrough suites using majority writes should have voting secondaries&lt;/p&gt;

&lt;h6&gt;&lt;a name=&quot;Originaldescription&quot;&gt;&lt;/a&gt;Original description&lt;/h6&gt;
&lt;p&gt;The changes in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-31670&quot; title=&quot;Change replica set fixture used by replica_sets_jscore_passthrough to make its secondary have zero votes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-31670&quot;&gt;&lt;del&gt;SERVER-31670&lt;/del&gt;&lt;/a&gt; made suites using the ReplicaSetFixture have non-voting secondaries by default unless &lt;tt&gt;voting_secondaries: true&lt;/tt&gt; or &lt;tt&gt;all_nodes_electable:True&lt;/tt&gt; was specified in the fixture configuration.&lt;/p&gt;

&lt;p&gt;The majority write passthrough suites which use majority writes by default should be updated to have voting secondaries. Otherwise the majority writes are only on the primary, so there isn&apos;t much of a purpose to the passthrough.&lt;/p&gt;

&lt;p&gt;The following suites should probably just need &lt;tt&gt;voting_secondaries: true&lt;/tt&gt; set on the &lt;tt&gt;ReplicaSetFixture&lt;/tt&gt;:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;read_concern_majority_passthrough&lt;/li&gt;
	&lt;li&gt;read_concern_linearizable_passthrough&lt;/li&gt;
	&lt;li&gt;aggregation_read_concern_majority_passthrough&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I think the following suites which use majority writes by default should also be changed:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;change_streams_secondary_reads&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
        <key id="482495">SERVER-32691</key>
            <summary>Create passthrough for w=&quot;majority&quot; with 2-node replica set to address lost test coverage</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="2" iconUrl="https://jira.mongodb.org/images/icons/priorities/critical.svg">Critical - P2</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="13201">Fixed</resolution>
                                        <assignee username="max.hirschhorn@mongodb.com">Max Hirschhorn</assignee>
                                    <reporter username="kevin.albertson@mongodb.com">Kevin Albertson</reporter>
                        <labels>
                    </labels>
                <created>Fri, 12 Jan 2018 22:26:20 +0000</created>
                <updated>Mon, 30 Oct 2023 23:09:19 +0000</updated>
                            <resolved>Mon, 12 Feb 2018 16:31:35 +0000</resolved>
                                                    <fixVersion>3.2.20</fixVersion>
                    <fixVersion>3.4.14</fixVersion>
                    <fixVersion>3.6.3</fixVersion>
                    <fixVersion>3.7.2</fixVersion>
                                    <component>Testing Infrastructure</component>
                                        <votes>0</votes>
                                    <watches>14</watches>
                                                                                                                <comments>
                            <comment id="1815077" author="xgen-internal-githook" created="Sat, 24 Feb 2018 07:08:40 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;max.hirschhorn@mongodb.com&apos;, &apos;name&apos;: &apos;Max Hirschhorn&apos;, &apos;username&apos;: &apos;visemet&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32691&quot; title=&quot;Create passthrough for w=&amp;quot;majority&amp;quot; with 2-node replica set to address lost test coverage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32691&quot;&gt;&lt;del&gt;SERVER-32691&lt;/del&gt;&lt;/a&gt; Add write_concern_majority_passthrough_WT task in Evergreen.&lt;/p&gt;

&lt;p&gt;Also changes the aggregation_read_concern_majority_passthrough.yml,&lt;br/&gt;
read_concern_majority_passthrough.yml, and&lt;br/&gt;
write_concern_majority_passthrough.yml test suites to skip any&lt;br/&gt;
JavaScript tests that use the &quot;collMod&quot; command because it only supports&lt;br/&gt;
a w=1 writeConcern.&lt;/p&gt;

&lt;p&gt;(cherry picked from commit bb8ac01f052a7b4b5c042085334ce640a1ab8dd1)&lt;br/&gt;
Branch: v3.2&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/e59d00a7323cbe3c164ab41ef4c53a4638caba5d&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/e59d00a7323cbe3c164ab41ef4c53a4638caba5d&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1815076" author="xgen-internal-githook" created="Sat, 24 Feb 2018 07:08:39 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;max.hirschhorn@mongodb.com&apos;, &apos;name&apos;: &apos;Max Hirschhorn&apos;, &apos;username&apos;: &apos;visemet&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32691&quot; title=&quot;Create passthrough for w=&amp;quot;majority&amp;quot; with 2-node replica set to address lost test coverage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32691&quot;&gt;&lt;del&gt;SERVER-32691&lt;/del&gt;&lt;/a&gt; Add write_concern_majority_passthrough.yml test suite.&lt;/p&gt;

&lt;p&gt;Reverts to emulating the write concern to work around how prior to&lt;br/&gt;
MongoDB 3.4, operations that did writes didn&apos;t necessarily accept a&lt;br/&gt;
writeConcern object.&lt;/p&gt;

&lt;p&gt;Also limits the usage of replica set connection strings to only the&lt;br/&gt;
write_concern_majority_passthrough.yml test suite to work around the&lt;br/&gt;
lack of complete support of MongoURI parsing in versions of the mongo&lt;br/&gt;
shell prior to MongoDB 3.4.&lt;/p&gt;

&lt;p&gt;(cherry picked from commit 264d971842cffdf8b4f80def1d90241f132345b7)&lt;br/&gt;
Branch: v3.2&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/e54239b3b99687ab79048f4ae0f20b2095910e18&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/e54239b3b99687ab79048f4ae0f20b2095910e18&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1806246" author="xgen-internal-githook" created="Wed, 14 Feb 2018 22:28:52 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;max.hirschhorn@mongodb.com&apos;, &apos;name&apos;: &apos;Max Hirschhorn&apos;, &apos;username&apos;: &apos;visemet&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32691&quot; title=&quot;Create passthrough for w=&amp;quot;majority&amp;quot; with 2-node replica set to address lost test coverage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32691&quot;&gt;&lt;del&gt;SERVER-32691&lt;/del&gt;&lt;/a&gt; Add write_concern_majority_passthrough_WT task in Evergreen.&lt;/p&gt;

&lt;p&gt;Modifies the usages of DBCommandCursor to work around how if the&lt;br/&gt;
CursorTracker is registered on the replica set connection (i.e. the&lt;br/&gt;
DBClientRS instance), then it&apos;ll trigger a verify() failure when garbage&lt;br/&gt;
collection occurs.&lt;/p&gt;

&lt;p&gt;Also changes the aggregation_read_concern_majority_passthrough.yml,&lt;br/&gt;
read_concern_majority_passthrough.yml, and&lt;br/&gt;
write_concern_majority_passthrough.yml test suites to skip any&lt;br/&gt;
JavaScript tests that use the &quot;collMod&quot; command because it only supports&lt;br/&gt;
a w=1 writeConcern.&lt;/p&gt;

&lt;p&gt;(cherry picked from commit bb8ac01f052a7b4b5c042085334ce640a1ab8dd1)&lt;br/&gt;
Branch: v3.4&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/6408164d14181b8717bdcb462456a90c16020a42&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/6408164d14181b8717bdcb462456a90c16020a42&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1806245" author="xgen-internal-githook" created="Wed, 14 Feb 2018 22:28:51 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;max.hirschhorn@mongodb.com&apos;, &apos;name&apos;: &apos;Max Hirschhorn&apos;, &apos;username&apos;: &apos;visemet&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32691&quot; title=&quot;Create passthrough for w=&amp;quot;majority&amp;quot; with 2-node replica set to address lost test coverage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32691&quot;&gt;&lt;del&gt;SERVER-32691&lt;/del&gt;&lt;/a&gt; Add write_concern_majority_passthrough.yml test suite.&lt;/p&gt;

&lt;p&gt;Also adds support for using replica set connection strings in resmoke.py&lt;br/&gt;
without making all nodes electable.&lt;/p&gt;

&lt;p&gt;(cherry picked from commit 264d971842cffdf8b4f80def1d90241f132345b7)&lt;br/&gt;
Branch: v3.4&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/7585ab8e5a5fd1b1c2f5926a98cf12387d717fa9&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/7585ab8e5a5fd1b1c2f5926a98cf12387d717fa9&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1802990" author="xgen-internal-githook" created="Mon, 12 Feb 2018 16:48:32 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;max.hirschhorn@mongodb.com&apos;, &apos;name&apos;: &apos;Max Hirschhorn&apos;, &apos;username&apos;: &apos;visemet&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32691&quot; title=&quot;Create passthrough for w=&amp;quot;majority&amp;quot; with 2-node replica set to address lost test coverage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32691&quot;&gt;&lt;del&gt;SERVER-32691&lt;/del&gt;&lt;/a&gt; Add write_concern_majority_passthrough_WT task in Evergreen.&lt;/p&gt;

&lt;p&gt;(cherry picked from commit bb8ac01f052a7b4b5c042085334ce640a1ab8dd1)&lt;br/&gt;
Branch: v3.6&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/5ccb16c2b8eb80d1eb3fe4e6ba36c092e03eb5d4&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/5ccb16c2b8eb80d1eb3fe4e6ba36c092e03eb5d4&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1802989" author="xgen-internal-githook" created="Mon, 12 Feb 2018 16:48:31 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;max.hirschhorn@mongodb.com&apos;, &apos;name&apos;: &apos;Max Hirschhorn&apos;, &apos;username&apos;: &apos;visemet&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32691&quot; title=&quot;Create passthrough for w=&amp;quot;majority&amp;quot; with 2-node replica set to address lost test coverage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32691&quot;&gt;&lt;del&gt;SERVER-32691&lt;/del&gt;&lt;/a&gt; Add write_concern_majority_passthrough.yml test suite.&lt;/p&gt;

&lt;p&gt;Also adds support for using replica set connection strings in resmoke.py&lt;br/&gt;
without making all nodes electable.&lt;/p&gt;

&lt;p&gt;(cherry picked from commit 264d971842cffdf8b4f80def1d90241f132345b7)&lt;br/&gt;
Branch: v3.6&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/b2399471de27583b684a1b4ad67195cab7062865&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/b2399471de27583b684a1b4ad67195cab7062865&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1802947" author="xgen-internal-githook" created="Mon, 12 Feb 2018 16:27:21 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;max.hirschhorn@mongodb.com&apos;, &apos;name&apos;: &apos;Max Hirschhorn&apos;, &apos;username&apos;: &apos;visemet&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32691&quot; title=&quot;Create passthrough for w=&amp;quot;majority&amp;quot; with 2-node replica set to address lost test coverage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32691&quot;&gt;&lt;del&gt;SERVER-32691&lt;/del&gt;&lt;/a&gt; Add write_concern_majority_passthrough task in Evergreen.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/bb8ac01f052a7b4b5c042085334ce640a1ab8dd1&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/bb8ac01f052a7b4b5c042085334ce640a1ab8dd1&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1802046" author="max.hirschhorn@10gen.com" created="Sat, 10 Feb 2018 20:58:03 +0000"  >&lt;p&gt;I&apos;m reopening this ticket because upon cherry-picking the changes from &lt;a href=&quot;https://github.com/mongodb/mongo/commit/264d971842cffdf8b4f80def1d90241f132345b7&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;264d971&lt;/a&gt; to the 3.6 branch, I realized that the lack of merge conflicts in &lt;tt&gt;etc/evergreen.yml&lt;/tt&gt; meant I never actually integrated the &lt;tt&gt;write_concern_majority_passthrough.yml&lt;/tt&gt; test suite into Evergreen.&lt;/p&gt;</comment>
                            <comment id="1790007" author="xgen-internal-githook" created="Wed, 31 Jan 2018 00:47:17 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;max.hirschhorn@mongodb.com&apos;, &apos;name&apos;: &apos;Max Hirschhorn&apos;, &apos;username&apos;: &apos;visemet&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32691&quot; title=&quot;Create passthrough for w=&amp;quot;majority&amp;quot; with 2-node replica set to address lost test coverage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32691&quot;&gt;&lt;del&gt;SERVER-32691&lt;/del&gt;&lt;/a&gt; Add write_concern_majority_passthrough.yml test suite.&lt;/p&gt;

&lt;p&gt;Also adds support for using replica set connection strings in resmoke.py&lt;br/&gt;
without making all nodes electable.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/264d971842cffdf8b4f80def1d90241f132345b7&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/264d971842cffdf8b4f80def1d90241f132345b7&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1779660" author="schwerin" created="Fri, 19 Jan 2018 22:19:21 +0000"  >&lt;p&gt;Talked to Judah. This SGTM. Thanks for thinking about this, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=max.hirschhorn&quot; class=&quot;user-hover&quot; rel=&quot;max.hirschhorn&quot;&gt;max.hirschhorn&lt;/a&gt; and &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=judah.schvimer&quot; class=&quot;user-hover&quot; rel=&quot;judah.schvimer&quot;&gt;judah.schvimer&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="1779058" author="judah.schvimer" created="Fri, 19 Jan 2018 15:54:31 +0000"  >&lt;p&gt;I&apos;m on board with the above. I filed &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-32794&quot; title=&quot;Make timeouts unrelated to elections not depend on election timeout&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-32794&quot;&gt;&lt;del&gt;SERVER-32794&lt;/del&gt;&lt;/a&gt; to address the stated timeout problem.&lt;/p&gt;</comment>
                            <comment id="1778547" author="max.hirschhorn@10gen.com" created="Fri, 19 Jan 2018 00:03:14 +0000"  >&lt;blockquote&gt;
&lt;p&gt;The w:majority writes aren&apos;t really testing this, the &quot;awaitReplication&quot; call is, which we do in all of our passthroughs, so these aren&apos;t really increasing coverage of that.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;Precisely - I meant this in the sense that specifying w=&quot;majority&quot; doesn&apos;t cause the primary to write different oplog entries or have those oplog entries be processed differently by a secondary. The dbhash check always needs to a w=&quot;all&quot; to ensure that all nodes in the replica set have processed all write operations because it doesn&apos;t treat 2-node replica sets specially.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;I don&apos;t really agree. If there were a bug where we waited for replication but replication didn&apos;t happen, we&apos;d catch that if we had a majority greater than 1.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;Your example of there being a bug with w=&quot;majority&quot; hanging when the size of the majority in the replica set is &amp;gt;1 node has convinced me that there is value in having voting secondaries for a w=&quot;majority&quot; passthrough.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Should we do secondary local reads after w:majority writes then?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;I think we could do as you described for testing w=&quot;majority&quot; with a 2-node replica set, but since we&apos;re talking about the &lt;tt&gt;*read_concern_majority_passthrough.yml&lt;/tt&gt; test suites, we&apos;d need to keep using readConcern={level: &quot;majority&quot;}.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=schwerin&quot; class=&quot;user-hover&quot; rel=&quot;schwerin&quot;&gt;schwerin&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=judah.schvimer&quot; class=&quot;user-hover&quot; rel=&quot;judah.schvimer&quot;&gt;judah.schvimer&lt;/a&gt;, what do you think about keeping the &lt;tt&gt;*read_concern_majority_passthrough.yml&lt;/tt&gt; test suites with &lt;tt&gt;voting_secondaries=false&lt;/tt&gt; and introducing a new &lt;tt&gt;write_concern_majority_passthrough.yml&lt;/tt&gt; test suite that performs reads on the secondary in a 2-node replica set? That feels more explicit to me about what we&apos;re actually trying to test with these different test suites.&lt;/p&gt;

&lt;p&gt;My goal is to remove &quot;an unexpected election caused a JavaScript test to fail&quot; from the class of failures the Replication team needs to deal with because we tend to blame them on the machine being slow anyway. My push to maximize the number of test suites that using &lt;tt&gt;voting_secondaries=false&lt;/tt&gt; is to make it so that failovers only happen in test suites that are prepared to handle (i.e. the stepdown ones). I would want to be able to have a &lt;tt&gt;write_concern_majority_passthrough.yml&lt;/tt&gt; test suite run with an election timeout of infinity while still using a heartbeat interval of 2 seconds and maxTimeMS on oplog getMores of 5 seconds for consistency with the default values. My impression is that using &quot;half of the election timeout&quot; is pervasive throughout parts of the replication codebase and&#8212;from a Slack conversation with Judah&#8212;that &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-29946&quot; title=&quot;Increase heartbeat rate when a secondary has no sync source&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-29946&quot;&gt;&lt;del&gt;SERVER-29946&lt;/del&gt;&lt;/a&gt; didn&apos;t necessarily go far enough to address this behavior.&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;&lt;a href=&quot;https://github.com/mongodb/mongo/blob/9b6f404d30b944def9bcc77ebc8277fb97471080/src/mongo/db/repl/sync_source_feedback.cpp#L56&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/blob/9b6f404d30b944def9bcc77ebc8277fb97471080/src/mongo/db/repl/sync_source_feedback.cpp#L56&lt;/a&gt;&lt;/li&gt;
	&lt;li&gt;&lt;a href=&quot;https://github.com/mongodb/mongo/blob/9b6f404d30b944def9bcc77ebc8277fb97471080/src/mongo/db/repl/oplog_fetcher.cpp#L74&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/blob/9b6f404d30b944def9bcc77ebc8277fb97471080/src/mongo/db/repl/oplog_fetcher.cpp#L74&lt;/a&gt;&lt;/li&gt;
	&lt;li&gt;&lt;a href=&quot;https://github.com/mongodb/mongo/blob/9b6f404d30b944def9bcc77ebc8277fb97471080/src/mongo/db/repl/topology_coordinator.cpp#L1018&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/blob/9b6f404d30b944def9bcc77ebc8277fb97471080/src/mongo/db/repl/topology_coordinator.cpp#L1018&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="1777988" author="judah.schvimer" created="Thu, 18 Jan 2018 17:24:48 +0000"  >&lt;blockquote&gt;
&lt;p&gt;the size of &quot;majority&quot; for the passthrough testing wasn&apos;t a significant factor in exercising correctness properties we are already testing.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I don&apos;t really agree. If there were a bug where we waited for replication but replication didn&apos;t happen, we&apos;d catch that if we had a majority greater than 1.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;In particular, performing a w=&quot;majority&quot; write doesn&apos;t guarantee that you can perform a readConcern={level: majority} read on a secondary and read your write because the logic to wait for the majority-committed snapshot to advance only occurs on the current primary. This means that the *read_concern_majority_passthrough.yml test suites cannot be used to test that w=&quot;majority&quot; writes actually wait for replication. &lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Should we do secondary local reads after w:majority writes then?&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;(2) that the data is eventually replicated to the secondaries.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;The w:majority writes aren&apos;t really testing this, the &quot;awaitReplication&quot; call is, which we do in all of our passthroughs, so these aren&apos;t really increasing coverage of that.&lt;/p&gt;</comment>
                            <comment id="1776440" author="max.hirschhorn@10gen.com" created="Wed, 17 Jan 2018 14:21:49 +0000"  >&lt;blockquote&gt;
&lt;p&gt;I&apos;m not enthusiastic about using voting but unelectable nodes as a way to ensure that the majority machinery runs without inducing elections. I worry that in a set where only 1 node is electable but many nodes can vote, some important consensus machinery may get excluded. After all, if only 1 node can win an election, and everyone agrees to that, there&apos;s no real point in the consensus machinery. The fact that we still use it in that case might be considered an implementation detail.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=schwerin&quot; class=&quot;user-hover&quot; rel=&quot;schwerin&quot;&gt;schwerin&lt;/a&gt;, I had discussed the impact on the readConcern={level: majority} test suites with &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=siyuan.zhou&quot; class=&quot;user-hover&quot; rel=&quot;siyuan.zhou&quot;&gt;siyuan.zhou&lt;/a&gt; on Jan 5th and we had reached a conclusion that the size of &quot;majority&quot; for the passthrough testing wasn&apos;t a significant factor in exercising correctness properties we are already testing. In particular, performing a w=&quot;majority&quot; write doesn&apos;t guarantee that you can perform a readConcern={level: majority} read &lt;b&gt;on a secondary&lt;/b&gt; and read your write because the logic to wait for the majority-committed snapshot to advance only occurs on the current primary. This means that the &lt;tt&gt;*read_concern_majority_passthrough.yml&lt;/tt&gt; test suites cannot be used to test that w=&quot;majority&quot; writes actually wait for replication. Given this limitation, my impression is that we are using the &lt;tt&gt;*read_concern_majority_passthrough.yml&lt;/tt&gt; test suite to verify that (1) the majority-committed snapshot is advanced and (2) that the data is eventually replicated to the secondaries.&lt;/p&gt;

&lt;p&gt;(If we were going to change the implementation of mongod such that readConcern={level: majority} invoked parts of the consensus machinery, then I would want to have voting secondaries.)&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;I think the following suites which use majority writes by default should also be changed:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;change_streams_secondary_reads&lt;/li&gt;
&lt;/ul&gt;
&lt;/blockquote&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kevin.albertson&quot; class=&quot;user-hover&quot; rel=&quot;kevin.albertson&quot;&gt;kevin.albertson&lt;/a&gt;, I don&apos;t see how this test suite isn&apos;t failing if we are performing reads on the secondary but only ensure that writes have made it to the primary.&lt;/p&gt;</comment>
                            <comment id="1774850" author="schwerin" created="Tue, 16 Jan 2018 11:47:40 +0000"  >&lt;p&gt;Yeah. I think the odds of us introducing a regression in the next week or two are pretty low; especially one not caught by the causal consistency passthroughs.&lt;/p&gt;</comment>
                            <comment id="1774659" author="cristopher.stauffer" created="Tue, 16 Jan 2018 02:22:42 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=schwerin&quot; class=&quot;user-hover&quot; rel=&quot;schwerin&quot;&gt;schwerin&lt;/a&gt; We have Max back on Wednesday - is that soon enough to review?&lt;/p&gt;</comment>
                            <comment id="1773681" author="schwerin" created="Sat, 13 Jan 2018 15:29:12 +0000"  >&lt;p&gt;I&apos;m not enthusiastic about using voting but unelectable nodes as a way to ensure that the majority machinery runs without inducing elections.  I worry that in a set where only 1 node is electable but many nodes can vote, some important consensus machinery may get excluded. After all, if only 1 node can win an election, and everyone agrees to that, there&apos;s no real point in the consensus machinery. The fact that we still use it in that case might be considered an implementation detail.&lt;/p&gt;</comment>
                            <comment id="1773462" author="william.schultz" created="Fri, 12 Jan 2018 22:54:16 +0000"  >&lt;p&gt;An alternative approach, so that we still test majority writes but avoid spurious elections, is to make the election timeouts in these suites very high, and set the priority of secondary nodes to zero. This would, hopefully, make primary&apos;s much more stable, even if they become slow or have communicating with other members of the set for some periods of time. Making the secondaries priority zero would make sure they don&apos;t trigger spurious elections if we want the primary to remain stable.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10420">
                    <name>Backports</name>
                                            <outwardlinks description="backported by">
                                                        </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                        <issuelink>
            <issuekey id="420507">SERVER-30850</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="478107">SERVER-32522</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="515965">SERVER-34116</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="416233">SERVER-30642</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="484518">SERVER-32774</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="448855">SERVER-31670</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="484929">SERVER-32794</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>18.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_12450" key="com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes">
                        <customfieldname>Backport Requested</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="15141"><![CDATA[v3.6]]></customfieldvalue>
    <customfieldvalue key="14340"><![CDATA[v3.4]]></customfieldvalue>
    <customfieldvalue key="13440"><![CDATA[v3.2]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10038"><![CDATA[Fully Compatible]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Fri, 12 Jan 2018 22:54:16 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        5 years, 50 weeks, 4 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[<s><a href='https://jira.mongodb.org/browse/SERVER-32522'>SERVER-32522</a></s>, <s><a href='https://jira.mongodb.org/browse/SERVER-30850'>SERVER-30850</a></s>]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>luke.bonanomi@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            5 years, 50 weeks, 4 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10026"><![CDATA[ALL]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>schwerin@mongodb.com</customfieldvalue>
            <customfieldvalue>cristopher.stauffer@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>judah.schvimer@mongodb.com</customfieldvalue>
            <customfieldvalue>kevin.albertson@mongodb.com</customfieldvalue>
            <customfieldvalue>max.hirschhorn@mongodb.com</customfieldvalue>
            <customfieldvalue>william.schultz@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|htnxmv:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|htffhr:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="2102">TIG 2018-02-12</customfieldvalue>
    <customfieldvalue id="2113">TIG 2018-02-26</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|htnjrb:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>