<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 04:38:20 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-34943] failCommand failpoint should ignore commands from replica set members</title>
                <link>https://jira.mongodb.org/browse/SERVER-34943</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;When a secondary runs a command on the primary, it will trigger the failCommand failpoint. This is unexpected for drivers because we would like to use failCommand to test retryable writes and transactions on replica sets.&lt;/p&gt;

&lt;p&gt;Some options I see:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;change failCommand to ignore commands from replica set members&lt;/li&gt;
	&lt;li&gt;change failCommand to ignore all commands except those in the &lt;tt&gt;sessionCheckoutWhitelist&lt;/tt&gt;?&lt;/li&gt;
	&lt;li&gt;drivers only use failCommand against single node replica sets or standalone servers&lt;/li&gt;
	&lt;li&gt;drivers never use the &quot;skip&quot; and &quot;times&quot; options and instead configure the failpoint as &quot;alwaysOn&quot; or &quot;off&quot;&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=spencer&quot; class=&quot;user-hover&quot; rel=&quot;spencer&quot;&gt;spencer&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
        <key id="542358">SERVER-34943</key>
            <summary>failCommand failpoint should ignore commands from replica set members</summary>
                <type id="4" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14710&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</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="jesse@mongodb.com">A. Jesse Jiryu Davis</assignee>
                                    <reporter username="shane.harvey@mongodb.com">Shane Harvey</reporter>
                        <labels>
                    </labels>
                <created>Thu, 10 May 2018 22:15:58 +0000</created>
                <updated>Mon, 8 Jan 2024 15:23:18 +0000</updated>
                            <resolved>Tue, 8 Jan 2019 22:28:32 +0000</resolved>
                                                    <fixVersion>4.0.6</fixVersion>
                    <fixVersion>4.1.7</fixVersion>
                                    <component>Replication</component>
                                        <votes>0</votes>
                                    <watches>15</watches>
                                                                                                                <comments>
                            <comment id="2135502" author="xgen-internal-githook" created="Fri, 1 Feb 2019 21:10:42 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;vincentkam&apos;, &apos;email&apos;: &apos;vincent.kam@10gen.com&apos;, &apos;username&apos;: &apos;vincentkam&apos;}
&lt;p&gt;Message: Update retryable-reads tests to use &quot;operations&quot;&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Update tests to use &quot;operations&quot; instead of &quot;operation&quot;&lt;/li&gt;
	&lt;li&gt;Update README to reflect the use of an array named &quot;operations&quot;&lt;br/&gt;
  instead of a single &quot;operation&quot;&lt;/li&gt;
	&lt;li&gt;Remove unneeded reference to &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-34943&quot; title=&quot;failCommand failpoint should ignore commands from replica set members&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-34943&quot;&gt;&lt;del&gt;SERVER-34943&lt;/del&gt;&lt;/a&gt;&lt;/li&gt;
	&lt;li&gt;Update formatting minimally&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/specifications/commit/45c92ffa1a9b8f3fbbc08ebbbcd9e473d8f4c0bf&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/specifications/commit/45c92ffa1a9b8f3fbbc08ebbbcd9e473d8f4c0bf&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="2119962" author="xgen-internal-githook" created="Fri, 18 Jan 2019 03:10:23 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;username&apos;: &apos;ajdavis&apos;, &apos;email&apos;: &apos;jesse@mongodb.com&apos;, &apos;name&apos;: &apos;A. Jesse Jiryu Davis&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-34943&quot; title=&quot;failCommand failpoint should ignore commands from replica set members&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-34943&quot;&gt;&lt;del&gt;SERVER-34943&lt;/del&gt;&lt;/a&gt; Ignore internal commands with &quot;failCommand&quot;&lt;br/&gt;
Branch: v4.0&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/fd490e4b0e9776dcc79ff21ae17e3c078d0cbc8f&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/fd490e4b0e9776dcc79ff21ae17e3c078d0cbc8f&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2117354" author="shane.harvey" created="Wed, 16 Jan 2019 19:09:05 +0000"  >&lt;p&gt;Yes we would like to use the failCommand fail point to test the behavior of find/getMore within a transaction without clashing with find/getMores from secondaries. For example, the&#160;&lt;a href=&quot;https://github.com/mongodb/specifications/blob/44daee8/source/transactions/tests/error-labels.yml#L288&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;&lt;tt&gt;&quot;add transient label to connection errors&quot;&lt;/tt&gt;&lt;/a&gt; test can be extended to include getMore as well.&lt;/p&gt;</comment>
                            <comment id="2116255" author="jesse" created="Tue, 15 Jan 2019 20:54:35 +0000"  >&lt;p&gt;Another question about the backport: since we&apos;re not testing sharded transactions or retryable reads in 4.0.x, &lt;b&gt;and&lt;/b&gt; the transactions tests we want for 4.0 replica sets only test writes, is it actually necessary to backport this ticket to 4.0? This ticket prevents a find or getMore from a secondary from spuriously triggering a failpoint, but the transactions tests mostly do writes. Remind me: the backport&apos;s needed because some of the transactions tests &lt;b&gt;do&lt;/b&gt; involve find and getMore?&lt;/p&gt;

&lt;p&gt;Thanks.&lt;/p&gt;</comment>
                            <comment id="2116105" author="jesse" created="Tue, 15 Jan 2019 19:26:52 +0000"  >&lt;p&gt;It&apos;s &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-35518&quot; title=&quot;Support the failCommand fail point in mongoS&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-35518&quot;&gt;&lt;del&gt;SERVER-35518&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="2116056" author="jmikola@gmail.com" created="Tue, 15 Jan 2019 19:07:36 +0000"  >&lt;p&gt;I think the primary use case for &lt;tt&gt;failCommand&lt;/tt&gt; is related to transactions, so I think we can do without backporting the fail point support to mongos 4.0.x. IIRC, the only other place drivers use this fail point is in retryable writes&apos; &lt;a href=&quot;https://github.com/mongodb/specifications/tree/master/source/retryable-writes/tests#network-error-tests&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Network Error Tests&lt;/a&gt; &amp;#8211; we don&apos;t run those tests on mongos due to the missing fail point today, so I think it&apos;s fine if we defer doing so until 4.2+.&lt;/p&gt;

&lt;p&gt;Can you point me to the server ticket where &lt;tt&gt;failCommand&lt;/tt&gt; support was added to mongos in 4.2? I&apos;d like to create a spec ticket to instruct drivers to start running those retryable writes test on mongos 4.2+.&lt;/p&gt;</comment>
                            <comment id="2116015" author="jesse" created="Tue, 15 Jan 2019 18:39:36 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jmikola&quot; class=&quot;user-hover&quot; rel=&quot;jmikola&quot;&gt;jmikola&lt;/a&gt;, it was pointed out to me that mongos doesn&apos;t support the failCommand fail point at all in 4.0.x. Do you think it&apos;s worth backporting the whole failCommand fail point to mongos for 4.0.x, or is it sufficient to backport the failCommand &lt;b&gt;fix&lt;/b&gt; for replica sets? I&apos;ve completed the replica set fix in a code review, the mongos backport would be much more effort.&lt;/p&gt;</comment>
                            <comment id="2109258" author="jesse" created="Tue, 8 Jan 2019 22:27:16 +0000"  >&lt;p&gt;Requesting backport to 4.0.&lt;/p&gt;</comment>
                            <comment id="2108640" author="jmikola@gmail.com" created="Tue, 8 Jan 2019 15:40:30 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jesse&quot; class=&quot;user-hover&quot; rel=&quot;jesse&quot;&gt;jesse&lt;/a&gt;: Is there another ticket for the requested backport to 4.0.x? If not, should this issue have a label indicating the backport request? Just want to make sure it wasn&apos;t overlooked.&lt;/p&gt;</comment>
                            <comment id="2088337" author="xgen-internal-githook" created="Wed, 12 Dec 2018 13:55:15 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;A. Jesse Jiryu Davis&apos;, &apos;email&apos;: &apos;jesse@mongodb.com&apos;, &apos;username&apos;: &apos;ajdavis&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-34943&quot; title=&quot;failCommand failpoint should ignore commands from replica set members&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-34943&quot;&gt;&lt;del&gt;SERVER-34943&lt;/del&gt;&lt;/a&gt; Ignore internal commands with &quot;failCommand&quot;&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/597b4748fc36210c61cf4d6c086d364013df740a&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/597b4748fc36210c61cf4d6c086d364013df740a&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2086340" author="jesse" created="Mon, 10 Dec 2018 21:49:32 +0000"  >&lt;p&gt;Drivers team (&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=shane.harvey&quot; class=&quot;user-hover&quot; rel=&quot;shane.harvey&quot;&gt;shane.harvey&lt;/a&gt; and &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=vincent.kam&quot; class=&quot;user-hover&quot; rel=&quot;vincent.kam&quot;&gt;vincent.kam&lt;/a&gt;) request a backport to 4.0.x for more consistent testing.&lt;/p&gt;</comment>
                            <comment id="2086267" author="jesse" created="Mon, 10 Dec 2018 20:58:52 +0000"  >&lt;p&gt;Oh good point, I was stuck in mistaken thinking. Yes, calling &quot;configureFailpoint&quot; on the mongos will work for testing Retryable Reads with a sharded cluster.&lt;/p&gt;</comment>
                            <comment id="2085370" author="schwerin" created="Mon, 10 Dec 2018 13:42:11 +0000"  >&lt;p&gt;Why not fail find commands in the router for testing sharded clusters? Is&lt;br/&gt;
it important that they fail at the shard?&lt;/p&gt;

&lt;p&gt;On Mon, Dec 10, 2018, 7:35 AM A. Jesse Jiryu Davis (Jira) &amp;lt;jira@mongodb.org&amp;gt;&lt;/p&gt;
</comment>
                            <comment id="2085326" author="jesse" created="Mon, 10 Dec 2018 12:34:02 +0000"  >&lt;p&gt;Actually, I think we need to reconsider.&lt;/p&gt;

&lt;p&gt;The goal is to test Retryable Reads with the failCommand failpoint, and ignore replication finds and getMores. Ignoring &quot;internalClient&quot; works great for that in a multi-node replica set, but it doesn&apos;t work in a &lt;b&gt;sharded cluster&lt;/b&gt; of multi-node replica sets. The problem is that mongos-&amp;gt;mongod connections are &lt;b&gt;also&lt;/b&gt; marked as &quot;internal&quot;. So if we want failCommand to fail the driver&apos;s &quot;find&quot; command in a sharded cluster, we have only uncomfortable options:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Add an override to failCommand so it &lt;b&gt;does&lt;/b&gt; fail internal commands, and then we must only test with sharded clusters of &lt;b&gt;single&lt;/b&gt;-node replica sets, as well as unsharded multi&amp;#45;node sets&lt;/li&gt;
	&lt;li&gt;Abandon this ticket and only test Retryable Reads with single-node replica sets and sharded clusters of them&lt;/li&gt;
	&lt;li&gt;Don&apos;t test retryable reads with sharded clusters at all&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I&apos;d like to propose a new &quot;replication: true&quot; parameter again. If failCommand ignores replication connections, we can fulfill the goal of testing Retryable Reads, and we can test it the &lt;b&gt;same&lt;/b&gt; with all topology types! This is much better.&lt;/p&gt;

&lt;p&gt;It&apos;s true that Andy&apos;s $out scenario will also appear to be a &quot;replication connection&quot;, but we don&apos;t plan to test that $out scenario with the failCommand failpoint, whereas we &lt;b&gt;do&lt;/b&gt; plan to test &quot;find&quot; and &quot;getMore&quot; with failCommand. I think that &quot;replication: true&quot; solves the problem we want to solve.&lt;/p&gt;</comment>
                            <comment id="2079064" author="jesse" created="Mon, 3 Dec 2018 20:33:43 +0000"  >&lt;p&gt;That sounds simple: &quot;failCommand ignores all internalClient connections&quot;. I&apos;ll proceed.&lt;/p&gt;</comment>
                            <comment id="2078603" author="tess.avitabile" created="Mon, 3 Dec 2018 16:55:25 +0000"  >&lt;p&gt;That&apos;s a good point. We have the &lt;tt&gt;internalClient&lt;/tt&gt; field in &lt;tt&gt;isMaster&lt;/tt&gt;, which is used to tag transport sessions with &lt;tt&gt;kInternalClient&lt;/tt&gt;. We could use that here.&lt;/p&gt;</comment>
                            <comment id="2078596" author="schwerin" created="Mon, 3 Dec 2018 16:52:19 +0000"  >&lt;p&gt;I&apos;m not a fan of it. For one thing, we can&apos;t actually distinguish &quot;replication&quot; vs other internal network connections, because they share a pool on the &quot;client node&quot;. For example, if you&apos;re doing aggregation with $out, a secondary might be sending $out writes to the primary of its own replica set as part of executing the user aggregation. That&apos;s not a &quot;replication&quot; connection, is it? What about when it&apos;s sending those writes to the primary of a different shard replica set? I think it will be difficult to manage.&lt;/p&gt;

&lt;p&gt;There may already be another signal that the connection is from an &quot;internal&quot; operator, though. Would that be enough? I think there&apos;s something because fcv uses it to control the reported wire protocol version. I&apos;ll find you IRL to chat, and we can sum up here after.&lt;/p&gt;</comment>
                            <comment id="2078534" author="jesse" created="Mon, 3 Dec 2018 16:29:47 +0000"  >&lt;p&gt;I don&apos;t think we should do the solution where failCommand ignores commands from the &amp;#95;&amp;#95;system user: that will require auth for testing (which is a new requirement) and if you forget to enable auth, some tests will fail some of the time for a very subtle reason. We&apos;ll have to remember that detail forever.&lt;/p&gt;

&lt;p&gt;I propose adding an isMaster parameter, &quot;replication: true&quot;, that&apos;s passed on the replication, initial-sync, and heartbeat connections. This allows replication connections to be tagged, and in&#160;shouldActivateFailCommandFailPoint we&apos;ll excuse replication connections from failCommand.&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;, we&apos;ve discussed extensions to isMaster in the past, do have objections to passing &quot;replication: true&quot; with the initial isMaster on replication connections?&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="2067912" author="vincent.kam" created="Tue, 20 Nov 2018 16:25:43 +0000"  >&lt;p&gt;Thanks &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=tess.avitabile&quot; class=&quot;user-hover&quot; rel=&quot;tess.avitabile&quot;&gt;tess.avitabile&lt;/a&gt;!&lt;/p&gt;</comment>
                            <comment id="2067144" author="tess.avitabile" created="Mon, 19 Nov 2018 22:10:00 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=vincent.kam&quot; class=&quot;user-hover&quot; rel=&quot;vincent.kam&quot;&gt;vincent.kam&lt;/a&gt;, thanks for the information. We will do our best to get this complete before driver testing starts.&lt;/p&gt;</comment>
                            <comment id="2066596" author="vincent.kam" created="Mon, 19 Nov 2018 17:23:32 +0000"  >&lt;p&gt;Thank you Tess!&lt;br/&gt;
 &amp;gt;&amp;gt; 1. Can you please help us determine the priority/timing of this work? When would the drivers plan to start retryable reads testing?&#160;&lt;/p&gt;

&lt;p&gt;The spec proof of concept is currently due 2019-1-15, so ideally it&apos;d be nice to have this ticket completed ~two weeks before then:&#160; my apologies for the tight timing!&lt;/p&gt;

&lt;p&gt;&amp;gt;&amp;gt; 2. Is it essential to test against multinode replica sets[?}&lt;/p&gt;

&lt;p&gt;Theoretically, drivers may be able to limit testing to mongoses and standalones, but it would be &lt;b&gt;highly&lt;/b&gt; desirable to test against multinode replica sets.&#160;&lt;/p&gt;

&lt;p&gt;&amp;gt;&amp;gt; 3. &lt;span class=&quot;error&quot;&gt;&amp;#91;I&amp;#93;&lt;/span&gt;s this the only way to test against multinode replica sets?&lt;/p&gt;

&lt;p&gt;Without the requested enhancements to failpoints, we currently do not see any way for drivers to test against multinode replica sets.&#160;&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;edit&amp;#93;&lt;/span&gt; Dates.&lt;/p&gt;

&lt;p&gt;cc: &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=behackett&quot; class=&quot;user-hover&quot; rel=&quot;behackett&quot;&gt;behackett&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=scott.lhommedieu&quot; class=&quot;user-hover&quot; rel=&quot;scott.lhommedieu&quot;&gt;scott.lhommedieu&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2065389" author="tess.avitabile" created="Fri, 16 Nov 2018 22:46:34 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=vincent.kam&quot; class=&quot;user-hover&quot; rel=&quot;vincent.kam&quot;&gt;vincent.kam&lt;/a&gt;, yes, that&apos;s something we could consider. I will reopen this ticket and put it in Needs Scheduling for us to triage. Can you please help us determine the priority/timing of this work? When would the drivers plan to start retryable reads testing? Is it essential to test against multinode replica sets, and is this the only way to test against multinode replica sets?&lt;/p&gt;</comment>
                            <comment id="2065133" author="vincent.kam" created="Fri, 16 Nov 2018 20:22:41 +0000"  >&lt;p&gt;I believe this issue will affect retryable reads testing. For example, my current understanding is that when trying to test a retryable &lt;tt&gt;db.coll.find(...)&lt;/tt&gt; on a replicaset, we would create a failPoint like so:&lt;/p&gt;
&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;{&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;	&quot;configureFailPoint&quot; : &quot;failCommand&quot;,&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;	&quot;mode&quot; : { times: 1 }&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;	&quot;data&quot; : {&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;		&quot;commands&quot; : [ &quot;find&quot; ],&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;		&quot;closeConnection&quot; : true&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;	}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;}&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;
&lt;p&gt;However, the secondaries tailing the oplog could trigger this failpoint, creating a race condition while testing. Would it be possible to implement the solution proposed by Andy and Spencer in the comments above?&lt;/p&gt;

&lt;p&gt;This issue isn&apos;t&apos; a blocker, as drivers could theoretically only test against only standalones, single node replicasets, and mongoses, but it would definitely be nice to test against multinode replicasets as that&apos;s one of the primary use cases for retryable reads.&lt;/p&gt;</comment>
                            <comment id="1898568" author="tess.avitabile" created="Tue, 22 May 2018 17:47:38 +0000"  >&lt;p&gt;Instead we will implement the more general solution in&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-35004&quot; title=&quot;Add functionality to only fail specific command(s) in failCommand failpoint&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-35004&quot;&gt;&lt;del&gt;SERVER-35004&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="1892251" author="shane.harvey" created="Tue, 15 May 2018 21:22:04 +0000"  >&lt;p&gt;I believe that drivers can work with either of those solutions. We are generally only interested in using failCommand to test retryable write commands both inside and outside transactions (including abortTransaction and commitTransaction).&lt;/p&gt;</comment>
                            <comment id="1892233" author="spencer" created="Tue, 15 May 2018 21:07:42 +0000"  >&lt;p&gt;Another alternative, which would be made possible if &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-34960&quot; title=&quot;Add a way to enter a failpoint without decrementing &amp;#39;times&amp;#39; or &amp;#39;skip&amp;#39;&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-34960&quot;&gt;&lt;del&gt;SERVER-34960&lt;/del&gt;&lt;/a&gt; gets completed, is that we instead of a whitelist of what commands are allowed, we provided a way to configure the failCommand failpoint with a blacklist of which specific commands it should fail.  Would that meet your needs &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=shane.harvey&quot; class=&quot;user-hover&quot; rel=&quot;shane.harvey&quot;&gt;shane.harvey&lt;/a&gt;?  &lt;b&gt;If&lt;/b&gt; we can get &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-34960&quot; title=&quot;Add a way to enter a failpoint without decrementing &amp;#39;times&amp;#39; or &amp;#39;skip&amp;#39;&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-34960&quot;&gt;&lt;del&gt;SERVER-34960&lt;/del&gt;&lt;/a&gt; in for 4.0, then I think that&apos;s probably the approach I&apos;d lean towards.  If we can&apos;t get &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-34960&quot; title=&quot;Add a way to enter a failpoint without decrementing &amp;#39;times&amp;#39; or &amp;#39;skip&amp;#39;&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-34960&quot;&gt;&lt;del&gt;SERVER-34960&lt;/del&gt;&lt;/a&gt; for 4.0, then we&apos;ll probably go with the access-control based solution.&lt;/p&gt;

&lt;p&gt;CC &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=mira.carey%40mongodb.com&quot; class=&quot;user-hover&quot; rel=&quot;mira.carey@mongodb.com&quot;&gt;mira.carey@mongodb.com&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1891162" author="shane.harvey" created="Mon, 14 May 2018 23:17:09 +0000"  >&lt;p&gt;Sounds good to me. I think we can easily limit these driver tests to only run against replica sets with access control enabled. &lt;/p&gt;</comment>
                            <comment id="1891132" author="spencer" created="Mon, 14 May 2018 22:41:30 +0000"  >&lt;p&gt;The simplest way to do this is probably as andy suggests and use the access control system.  We could skip activating the failpoint on connections authenticated as the __system user.  The downside to this approach is it wouldn&apos;t work when access control is disabled.  Does that work for you &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=shane.harvey&quot; class=&quot;user-hover&quot; rel=&quot;shane.harvey&quot;&gt;shane.harvey&lt;/a&gt;?&lt;/p&gt;</comment>
                            <comment id="1891130" author="spencer" created="Mon, 14 May 2018 22:37:52 +0000"  >&lt;p&gt;Oh wait, you might also have problems with the &apos;find&apos; and &apos;getmore&apos; commands used for replicating the oplog.  Then we probably do indeed also need a way to configure the failpoint to only activate for commands not sent by cluster members.&lt;/p&gt;</comment>
                            <comment id="1891129" author="spencer" created="Mon, 14 May 2018 22:36:39 +0000"  >&lt;p&gt;I think we should probably just add the &apos;replSetHeartbeat&apos;, &apos;replSetUpdatePosition&apos;, and &apos;replSetRequestVotes&apos; commands to the command whitelist for now.  Once &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-34960&quot; title=&quot;Add a way to enter a failpoint without decrementing &amp;#39;times&amp;#39; or &amp;#39;skip&amp;#39;&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-34960&quot;&gt;&lt;del&gt;SERVER-34960&lt;/del&gt;&lt;/a&gt; is in, we should consider bringing back the functionality to specify which commands should be ignored, and the list specified should override the default whitelist.  But I think the goal should be that the default whitelist is sufficient for most (all?) drivers testing, and we just use the ability to control which commands fail for testing server behavior.&lt;/p&gt;</comment>
                            <comment id="1889837" author="schwerin" created="Sat, 12 May 2018 14:41:24 +0000"  >&lt;p&gt;Another option is to adjust the failpoint to only count for specific users.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10420">
                    <name>Backports</name>
                                            <outwardlinks description="backported by">
                                                        </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                        <issuelink>
            <issuekey id="413981">DRIVERS-405</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="530551">SERVER-34551</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="635411">SERVER-38188</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="542708">SERVER-34960</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="544379">SERVER-35004</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>31.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="15640"><![CDATA[v4.0]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10011"><![CDATA[Minor Change]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Sat, 12 May 2018 14:41:24 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        5 years, 1 week, 5 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[]]></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, 1 week, 5 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>jesse@mongodb.com</customfieldvalue>
            <customfieldvalue>schwerin@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>jmikola@mongodb.com</customfieldvalue>
            <customfieldvalue>shane.harvey@mongodb.com</customfieldvalue>
            <customfieldvalue>spencer@mongodb.com</customfieldvalue>
            <customfieldvalue>tess.avitabile@mongodb.com</customfieldvalue>
            <customfieldvalue>vincent.kam@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|htxsjr:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hr8fr3:</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="2296">Repl 2018-06-04</customfieldvalue>
    <customfieldvalue id="2607">Repl 2018-12-17</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                <customfield id="customfield_10166" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Tests Written</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10154"><![CDATA[Complete]]></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|htxet3:</customfieldvalue>

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