<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:24:42 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-2093] How should drivers handle multiple WriteConcernErrors in a bulk operation</title>
                <link>https://jira.mongodb.org/browse/DRIVERS-2093</link>
                <project id="10980" key="DRIVERS">Drivers</project>
                    <description>&lt;p&gt;According to the CRUD spec, a &lt;tt&gt;BulkWriteException&lt;/tt&gt; contains an optional array of &lt;tt&gt;WriteError&lt;/tt&gt; s and a single optional &lt;tt&gt;WriteConcernError&lt;/tt&gt;. It isn&apos;t immediately clear to me based on the spec how drivers should handle the case of multiple write concern related errors.&lt;/p&gt;

&lt;p&gt;Our current implementations seem divided on this too:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;The C driver, for example, returns an &lt;a href=&quot;http://mongoc.org/libmongoc/current/bulk.html#bulk-operation-write-concerns&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;array of all the write concern errors&lt;/a&gt;.&lt;/li&gt;
	&lt;li&gt;The PHP driver simply &lt;a href=&quot;https://github.com/mongodb/mongo-php-driver/blob/1.5.3/src/MongoDB/WriteResult.c#L36&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;selects the first one&lt;/a&gt;.&lt;/li&gt;
	&lt;li&gt;The shell documentation &lt;a href=&quot;https://docs.mongodb.com/manual/reference/method/db.collection.bulkWrite/#bulk-write-with-write-concern&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;suggests that an array is returned&lt;/a&gt;.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;The &lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/driver-bulk-update.rst#write-concern-errors&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;legacy bulk-update spec&lt;/a&gt; opts for an array:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Previous versions of this spec were ambiguous about reporting writeConcernErrors. Some clients include a singular field &quot;writeConcernError&quot; in bulk results; the singular form is now deprecated and an array called &quot;writeConcernErrors&quot; is required.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Though I&apos;m not sure how relevant that spec is these days.&lt;/p&gt;

&lt;p&gt;So my questions are: &lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;If the spec is correct in specifying a single write concern error should be reported by a &lt;tt&gt;BulkWriteException&lt;/tt&gt; , how should drivers choose which one? Does it matter?&lt;/li&gt;
	&lt;li&gt;Or should the spec be updated such that all the write concern errors are reported?&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
        <key id="667824">DRIVERS-2093</key>
            <summary>How should drivers handle multiple WriteConcernErrors in a bulk operation</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="patrick.freed@mongodb.com">Patrick Freed</reporter>
                        <labels>
                    </labels>
                <created>Tue, 8 Jan 2019 23:07:33 +0000</created>
                <updated>Tue, 11 Oct 2022 15:34:52 +0000</updated>
                                                                <component>CRUD</component>
                                        <votes>0</votes>
                                    <watches>7</watches>
                                                                                                                <comments>
                            <comment id="4648905" author="kaitlin.mahar" created="Wed, 29 Jun 2022 19:46:16 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=isabel.atkinson%40mongodb.com&quot; class=&quot;user-hover&quot; rel=&quot;isabel.atkinson@mongodb.com&quot;&gt;isabel.atkinson@mongodb.com&lt;/a&gt; something to consider writing the new spec. linking to &lt;a href=&quot;https://jira.mongodb.org/browse/DRIVERS-716&quot; title=&quot;Improved Bulk Write API&quot; class=&quot;issue-link&quot; data-issue-key=&quot;DRIVERS-716&quot;&gt;DRIVERS-716&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2132549" author="shane.harvey" created="Wed, 30 Jan 2019 20:32:42 +0000"  >&lt;p&gt;Added the known types of errors to the read and write concern spec in SPEC-1207. Here&apos;s a link to the section: &lt;a href=&quot;https://github.com/mongodb/specifications/blob/master/source/read-write-concern/read-write-concern.rst#writeconcernerror-examples&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/specifications/blob/master/source/read-write-concern/read-write-concern.rst#writeconcernerror-examples&lt;/a&gt;  &lt;/p&gt;</comment>
                            <comment id="2131484" author="behackett" created="Wed, 30 Jan 2019 00:29:08 +0000"  >&lt;p&gt;Excellent. I stand corrected. Can we get that list into some relevant spec?&lt;/p&gt;</comment>
                            <comment id="2131423" author="shane.harvey" created="Tue, 29 Jan 2019 23:31:23 +0000"  >&lt;p&gt;While I agree that it should be a rare event, you can definitely have multiple different writeConcernErrors in practice, both on a replica set and sharded cluster. The set of possible&#160;writeConcernErrors is actually quite large because they include errors caused by shutdown, stepdown, interruption, maxTimeMS, and wtimeout. See &lt;a href=&quot;https://jira.mongodb.org/browse/SPEC-1063?focusedCommentId=1874169&amp;amp;page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1874169&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;my comment that attempts to list them all&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="2131414" author="behackett" created="Tue, 29 Jan 2019 23:22:38 +0000"  >&lt;p&gt;My argument wasn&apos;t that multiple WC errors can&apos;t occur. My argument was that it&apos;s unlikely that multiple &lt;em&gt;different&lt;/em&gt; WC errors would occur. What are the WC errors? We have (paraphrasing the error messages) &quot;not enough nodes to satisfy write concern&quot; (you configured w:5 but only have 4 members in the replica set config), &quot;journaling is disabled&quot; (you set &lt;tt&gt;j: true&lt;/tt&gt; but for some reason journaling is disabled in the server) and &quot;timed out waiting for replication&quot; (you set wtimeoutms to 500 and replication took longer than that). What else? The first two errors are fatal and will just be spammed for every operation you attempt. The third will likely be intermittent. Given the fatality of the first and second errors, I don&apos;t see how you can have two different WC errors when talking to a replica set. When talking to a sharded cluster I can see it, but since the first two are fatal and are seemingly a configuration mistake wtimeout seems like the only one we really have to care about.&lt;/p&gt;

&lt;p&gt;Maybe I&apos;m wrong about all the possible WC errors. Maybe the first step is to enumerate them.&lt;/p&gt;</comment>
                            <comment id="2131196" author="shane.harvey" created="Tue, 29 Jan 2019 21:13:51 +0000"  >&lt;p&gt;For reference, Pymongo adds any writeConcernErrors to a list and includes all of them in the &lt;tt&gt;BulkWriteError&lt;/tt&gt; raised to the user:&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;client &lt;/span&gt;&lt;span style=&quot;color: #006699; font-weight: bold; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;=&lt;/span&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; MongoClient(w&lt;/span&gt;&lt;span style=&quot;color: #006699; font-weight: bold; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;=&lt;/span&gt;&lt;span style=&quot;color: blue; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;&apos;majority&apos;&lt;/span&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;, wtimeoutms&lt;/span&gt;&lt;span style=&quot;color: #006699; font-weight: bold; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;=&lt;/span&gt;&lt;span style=&quot;color: #009900; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;1&lt;/span&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: #006699; font-weight: bold; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;try&lt;/span&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;    client.test.test.bulk_write(&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;        [InsertOne({&lt;/span&gt;&lt;span style=&quot;color: blue; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;&apos;a&apos;&lt;/span&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;span style=&quot;color: #009900; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;1&lt;/span&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;}), UpdateOne({&lt;/span&gt;&lt;span style=&quot;color: blue; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;&apos;a&apos;&lt;/span&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;span style=&quot;color: #009900; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;1&lt;/span&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;span style=&quot;color: blue; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;&apos;$set&apos;&lt;/span&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;span style=&quot;color: blue; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;&apos;a&apos;&lt;/span&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;span style=&quot;color: #009900; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;2&lt;/span&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: #006699; font-weight: bold; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;except&lt;/span&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; BulkWriteError as e:&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;span style=&quot;color: #ff1493; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;print&lt;/span&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;(e.details[&lt;/span&gt;&lt;span style=&quot;color: blue; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;&apos;writeConcernErrors&apos;&lt;/span&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 problem still remains that these errors are not correlated to a set of writes.&lt;/p&gt;</comment>
                            <comment id="2130573" author="jmikola@gmail.com" created="Tue, 29 Jan 2019 15:20:30 +0000"  >&lt;p&gt;From a chat session with &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; in {{#server-ds-replication }}:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;b&gt;jmikola&lt;/b&gt;: Are we in agreement that multiple WC errors can at least happen in practice (as outlined in my last comment in the spec ticket)? Before I go back to Bernie and ask about how to present them to users, I want to establish that the scenario could happen&lt;/p&gt;

&lt;p&gt;&lt;b&gt;tess&lt;/b&gt;: Yes, certainly. For example, if the node can no longer replicate to a majority, and all of the commands had majority writeConcern. And I agree with your comment that if the last command had successful writeConcern, and all commands had the same writeConcern and used the same connection, then all commands had successful writeConcern. It&apos;s a little subtle, though, since it relies on the fact that we close connections when entering rollback. But yes, this is only true for replica sets.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;jmikola&lt;/b&gt;: re: &quot;the fact that we close connections when entering rollback&quot; &amp;#8211; this is unrelated to 4.2 now keeping connections alive on step down (cursors survive primary stepdown spec), correct? I assume 4.2 servers will continue to close connections on rollbacks, but that&apos;s probably an implementation detail we shouldn&apos;t depend on&lt;/p&gt;

&lt;p&gt;&lt;b&gt;tess&lt;/b&gt;: Yes, 4.2 servers will still close connections on rollback, but I agree it&apos;s probably better not to rely on that.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;So, the take-away is that multiple WC errors &lt;em&gt;can&lt;/em&gt; happen over the course of a multi-command bulk write (i.e. &lt;tt&gt;insertMany()&lt;/tt&gt; and &lt;tt&gt;bulkWrite()&lt;/tt&gt;).&lt;/p&gt;

&lt;p&gt;It&apos;s still unclear how useful &lt;em&gt;any&lt;/em&gt; write concern error (i.e. &lt;tt&gt;BulkWriteException.writeConcernError&lt;/tt&gt;) will be for the user, since there&apos;s no association between that particular WC error and a write command executed during the batch &amp;#8211; noting that a WC error on the final command may be more relevant than one from an earlier command on the same socket.&lt;/p&gt;

&lt;p&gt;For now, I propose we continue to report the last seen WC error but consider allowing drivers to report all WC errors seen over the course of a bulk write.  This would constitute a spec change to allow/introduce a &lt;tt&gt;BulkWriteException.writeConcernErrors&lt;/tt&gt; array. I believe libmongoc already does this in &lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/blob/1.13.1/src/libmongoc/src/mongoc/mongoc-write-command.c#L1219&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;&lt;tt&gt;_mongoc_write_result_merge()&lt;/tt&gt;&lt;/a&gt; (see also: &lt;a href=&quot;http://mongoc.org/libmongoc/current/bulk.html#bulk-operation-write-concerns&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Bulk Operation Write Concerns&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Long term, we should probably discuss this with the product team and see if improving the way we report WC errors would be genuinely useful for our users (perhaps a list of indexes to which the WC error pertains).&lt;/p&gt;</comment>
                            <comment id="2130501" author="jmikola@gmail.com" created="Tue, 29 Jan 2019 14:29:20 +0000"  >&lt;blockquote&gt;&lt;p&gt;You&apos;re proposing that we shouldn&apos;t report it at all if the final batch doesn&apos;t have a write concern error? That might work for a replica set, but I&apos;m not sure it would for a sharded cluster.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;Naturally, I didn&apos;t consider sharding (this line would probably make for a great drinking game).&lt;/p&gt;

&lt;p&gt;Thinking about this some more, I also think there may even be complications for a replica set. Consider that an early write command in the batch hit a wtimeout on &lt;tt&gt;w:majority&lt;/tt&gt;, a subsequent write comment hit a failover but is successfully retried and replicates within the timeout. The failover could mean that the earlier write was never majority-acknowledged and rolled back &amp;#8211; so drivers would do well to raise that WC error to users.&lt;/p&gt;

&lt;p&gt;That said, the main point of my last comment wasn&apos;t about ignoring WC errors, although I definitely segued into that in my second paragraph. In the first paragraph, I was arguing that there is a legitimate case where multiple WC errors could be relevant to the user. If we consider this alongside retryable writes and potentially multiple failovers during the execution of a bulk write, I think it gets more complicated.&lt;/p&gt;

&lt;p&gt;Unlike write errors, WC errors are not with any operation index or write command (insert|update|delete) in the batch, so I&apos;m not even sure how users could meaningfully make sense of multiple WC errors. The best conclusion may just be &quot;I know something(s) in the batch failed to replicate and, depending on my WC, might have been rolled back&quot;. It may be worth to solicit some server team advice, so I&apos;ll see if I can get someone from &lt;tt&gt;#server-ds-replication&lt;/tt&gt; to chime in here.&lt;/p&gt;</comment>
                            <comment id="2130074" author="behackett" created="Mon, 28 Jan 2019 23:51:47 +0000"  >&lt;p&gt;I see what you&apos;re saying. Currently PyMongo, for example, would report the write concern error at the end of processing the unordered bulk operations. You&apos;re proposing that we shouldn&apos;t report it at all if the final batch doesn&apos;t have a write concern error? That might work for a replica set, but I&apos;m not sure it would for a sharded cluster. What happens if your last batch just doesn&apos;t hit the laggy shard(s)?&lt;/p&gt;</comment>
                            <comment id="2129677" author="jmikola@gmail.com" created="Mon, 28 Jan 2019 19:21:28 +0000"  >&lt;p&gt;&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;: I think it is possible for there to be multiple WC errors. Consider an unordered (effectively continue-on-error behavior) bulk write where the driver has organized operations into separate insert, update, and delete commands. The insert and update commands both time out awaiting replication and the driver receives a write concern error, while the delete command does replicate within the wtimeout period.&lt;/p&gt;

&lt;p&gt;Assuming all three commands were executed serially on the same connection, drivers should be able to trust that the write concern on the last issued command speaks for all previous writes. In the example above (insert and update time out, but final delete succeeds), drivers could disregard the previous write concern errors &amp;#8211; in effect, only the final command&apos;s WC error (or lack thereof) matters.&lt;/p&gt;

&lt;p&gt;That said, if a driver ever decided to execute bulk writes in parallel across different connections or the server allowed async command execution, this rule would go out the window as we could not reliably determine that the &quot;final&quot; command&apos;s WC response speaks for the others. &lt;/p&gt;

&lt;p&gt;Do you concur?&lt;/p&gt;</comment>
                            <comment id="2110328" author="patrick.freed" created="Wed, 9 Jan 2019 19:19:56 +0000"  >&lt;p&gt;Even when ordered is false, there&apos;s no possibility that different batches could have different write concern errors?&lt;/p&gt;</comment>
                            <comment id="2109369" author="behackett" created="Wed, 9 Jan 2019 00:17:43 +0000"  >&lt;p&gt;There will only be one write concern error, even if it is reported multiple times across batches (timed out waiting for replication, not enough data bearing nodes, etc.), so you don&apos;t need to report an array of them. On the other hand, you can have multiple different write errors (duplicate key, document too large, etc.) in a single batch, or across multiple batches, when ordered is false.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="900346">DRIVERS-716</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="668349">DRIVERS-2159</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="450315">DRIVERS-2090</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </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|hu8k4n:</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>