<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:24:45 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>[DRIVERS-2114] Unclear whether read preference must be sent in RS topologies</title>
                <link>https://jira.mongodb.org/browse/DRIVERS-2114</link>
                <project id="10980" key="DRIVERS">Drivers</project>
                    <description>&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/SPEC-1292&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/SPEC-1292&lt;/a&gt; prohibited sending read preference in standalone topologies. The server selection spec explicitly states how read preference should be passed to mongos. However when it comes to replica sets, read preference passing is not mentioned at all - it is neither required nor prohibited (e.g. in &lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/server-selection/server-selection.rst#read-preference&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/specifications/blob/master/source/server-selection/server-selection.rst#read-preference&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=matt.broadstone&quot; class=&quot;user-hover&quot; rel=&quot;matt.broadstone&quot;&gt;matt.broadstone&lt;/a&gt; Suggested that read preference should not be sent when in RS topologies. When I tried that, a number of transactions tests failed. Examining these tests e.g. &lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/transactions/tests/read-pref.yml&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/specifications/blob/master/source/transactions/tests/read-pref.yml&lt;/a&gt;, they contain read preference assertions and specify they should be run on RS and sharded topologies. Hence there appears to be an implicit requirement that drivers send read preferences when in RS topologies.&lt;/p&gt;</description>
                <environment></environment>
        <key id="836160">DRIVERS-2114</key>
            <summary>Unclear whether read preference must be sent in RS topologies</summary>
                <type id="14901" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14700&amp;avatarType=issuetype">Spec Change</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="10038" iconUrl="https://jira.mongodb.org/images/icons/subtask.gif" description="">Backlog</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="oleg.pudeyev@mongodb.com">Oleg Pudeyev</reporter>
                        <labels>
                    </labels>
                <created>Fri, 5 Jul 2019 19:44:39 +0000</created>
                <updated>Thu, 31 Mar 2022 13:52:55 +0000</updated>
                                                                                    <votes>0</votes>
                                    <watches>3</watches>
                                                                                                                <comments>
                            <comment id="3093608" author="jmikola@gmail.com" created="Mon, 18 May 2020 19:18:46 +0000"  >&lt;p&gt;With OP_QUERY, the &lt;tt&gt;slaveOk&lt;/tt&gt; bit was necessary for a secondary to respond to a query; however, &lt;tt&gt;$readPreference&lt;/tt&gt; seems to have no purpose outside of mongos. AFAIK, a replica set member will simply ignore this field.&lt;/p&gt;

&lt;p&gt;Is there any benefit for mandating that drivers include it for all non-standalone OP_MSG recipients, other than allowing drivers to utilize the same code path for replica sets and mongos when building an OP_MSG structure?&lt;/p&gt;</comment>
                            <comment id="2317196" author="rathi.gnanasekaran" created="Tue, 9 Jul 2019 15:23:39 +0000"  >&lt;p&gt;Will tackle after 4.2 work.&lt;/p&gt;</comment>
                            <comment id="2315522" author="david.golden" created="Mon, 8 Jul 2019 16:38:39 +0000"  >&lt;p&gt;This was never well-specified during the OP_MSG work.  I believe it should all be rewritten to clarify the differences between OP_QUERY and OP_MSG:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Topology Single
	&lt;ul&gt;
		&lt;li&gt;As currently specified&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;Topology ReplicaSet (with/without primary)
	&lt;ul&gt;
		&lt;li&gt;OP_MSG: send &lt;tt&gt;$readPreference&lt;/tt&gt; always&lt;/li&gt;
		&lt;li&gt;OP_QUERY: never send &lt;tt&gt;$readPreference&lt;/tt&gt;; set SlaveOK bit for non-primary read preference&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;Topology Sharded
	&lt;ul&gt;
		&lt;li&gt;OP_MSG: always send &lt;tt&gt;$readPreference&lt;/tt&gt;&lt;/li&gt;
		&lt;li&gt;OP_QUERY: always send &lt;tt&gt;$readPreference&lt;/tt&gt;; set SlaveOK bit for non-primary read preference&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I believe the legacy behavior of using only SlaveOK and not sending &lt;tt&gt;$readPreference&lt;/tt&gt; to a mongos for &quot;secondaryPreferred&quot; can be dispensed with.&lt;/p&gt;
</comment>
                            <comment id="2314267" author="matt.broadstone" created="Sat, 6 Jul 2019 17:54:27 +0000"  >&lt;p&gt;Hey &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=oleg.pudeyev&quot; class=&quot;user-hover&quot; rel=&quot;oleg.pudeyev&quot;&gt;oleg.pudeyev&lt;/a&gt;, I&apos;ve been thinking more about this and I think its probably the correct behavior to send &lt;tt&gt;$readPreference&lt;/tt&gt; when connected to replicasets (and of course for mongos). Like we were talking about the other day, upon first reflection the read preference is only a useful hint for a mongos since it informs the router how to make its own server selection. However, with &lt;tt&gt;OP_MSG&lt;/tt&gt; we have lost the &lt;tt&gt;slaveOk&lt;/tt&gt; bit which gives a node in a replicaset an opportunity to let the client know it&apos;s &quot;not master&quot;. Sending the &lt;tt&gt;$readPreference&lt;/tt&gt; along with messages to a replicaset gives us the opportunity to maintain this behavior in the absence of the &lt;tt&gt;slaveOk&lt;/tt&gt; bit. &lt;/p&gt;

&lt;p&gt;All of this is cryptically described in the &lt;tt&gt;OP_MSG&lt;/tt&gt;  specification in the &lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/message/OP_MSG.rst#global-command-arguments&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Global Command Arguments&lt;/a&gt;, with the somewhat unhelpful sentence:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;and also whether a secondary server permits reads or responds &quot;not master&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I would be supportive of improving this language, in particular to clarify why we want consistent command shapes for non-standalone connections, etc. &lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="797341">RUBY-1834</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="836156">DRIVERS-2050</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                            <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_10951" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Driver Changes</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10748"><![CDATA[Needed]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|huzy5j:</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>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        </customfields>
    </item>
</channel>
</rss>