<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 21:17:11 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>[CDRIVER-3121] Failpoint errors may not be considered a failure</title>
                <link>https://jira.mongodb.org/browse/CDRIVER-3121</link>
                <project id="10030" key="CDRIVER">C Driver</project>
                    <description>&lt;p&gt;Given the following code sample:&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: #006699; font-weight: bold; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;if&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; (!mongoc_collection_insert_one(collection, insert, NULL, &amp;amp;reply, &amp;amp;error)) {&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;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;printf&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;&quot;err inserting reply: %s err: %s\n&quot;&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;, bson_as_relaxed_extended_json(&amp;amp;reply, NULL), error.message);&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;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;else&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;            &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;printf&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;&quot;success: %s\n&quot;&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;, bson_as_relaxed_extended_json(&amp;amp;reply, NULL));&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;it prints&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;   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;success: { &quot;insertedCount&quot; : 1, &quot;writeConcernErrors&quot; : [ { &quot;code&quot; : 91.0, &quot;errmsg&quot; : &quot;Replication is being shut down&quot; } ] }&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;when encountering a write concern error. This means the function returned true, even though the docs state that a write concern error should be considered a failure. I believe this applies to the other crud functions as well (including bulk writes).&lt;/p&gt;</description>
                <environment></environment>
        <key id="763539">CDRIVER-3121</key>
            <summary>Failpoint errors may not be considered a failure</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</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="kevin.albertson@mongodb.com">Kevin Albertson</assignee>
                                    <reporter username="patrick.freed@mongodb.com">Patrick Freed</reporter>
                        <labels>
                    </labels>
                <created>Thu, 9 May 2019 19:29:52 +0000</created>
                <updated>Sat, 28 Oct 2023 11:29:17 +0000</updated>
                            <resolved>Fri, 13 Mar 2020 22:50:35 +0000</resolved>
                                                    <fixVersion>1.17.0-beta</fixVersion>
                    <fixVersion>1.17.0</fixVersion>
                                    <component>libmongoc</component>
                                        <votes>0</votes>
                                    <watches>3</watches>
                                                                                                                <comments>
                            <comment id="2979597" author="kevin.albertson" created="Fri, 13 Mar 2020 22:50:27 +0000"  >&lt;p&gt;The error codes should now accept double or int64 as well.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;It also appears that the write concern error will be present in the reply even if the write is retried and succeeds on the second attempt. The function will report success via the return value (not the reply) regardless of whether the write was retried successfully or not, though.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;I couldn&apos;t reproduce this, and reading the code, it does appear that write commands would retry before parsing a reply into a write result. I wonder if this was a surfacing of the same issue. Perhaps the failpoint triggered on the retry as well, and though the second reply has a writeConcernError, the return still indicated success. I&apos;m closing for now, but feel free to re-open if that isn&apos;t the case.&lt;/p&gt;</comment>
                            <comment id="2979592" author="xgen-internal-githook" created="Fri, 13 Mar 2020 22:45:10 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;username&apos;: &apos;kevinAlbs&apos;, &apos;name&apos;: &apos;Kevin Albertson&apos;, &apos;email&apos;: &apos;kevin.albertson@mongodb.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-3121&quot; title=&quot;Failpoint errors may not be considered a failure&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-3121&quot;&gt;&lt;del&gt;CDRIVER-3121&lt;/del&gt;&lt;/a&gt; loosen error code numeric checks&lt;/p&gt;

&lt;p&gt;Permit double and int64, since they may appear when&lt;br/&gt;
error codes are returned via failpoints.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/commit/4ea991488081d4f129947510647b34a640808840&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-c-driver/commit/4ea991488081d4f129947510647b34a640808840&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2369114" author="patrick.freed" created="Tue, 13 Aug 2019 18:41:30 +0000"  >&lt;p&gt;Regarding your second open question, it feels like the server&apos;s responsibility to standardize the types of their error codes, regardless of what the user sends them. I guess since failPoints are largely developer tools, they don&apos;t do a ton of sanitation right now, but I still find it very strange that it&apos;s even possible for the codes to be returned as multiple different types. I think the &lt;tt&gt;ok&lt;/tt&gt; field might suffer from this same issue.&lt;/p&gt;</comment>
                            <comment id="2369107" author="patrick.freed" created="Tue, 13 Aug 2019 18:38:01 +0000"  >&lt;p&gt;Blast from the past here&#8211;I glossed over the questions directed at me. Yep, I was using a full non-mocked mongod instance when I encountered this bug. For some reason, the server happens to include the exact error code as specified in the configureFailPoint command in its reply when the failPoint is triggered, preserving its type. The fail point does trigger correctly regardless of the that  type (assuming the same numeric value), however.&lt;/p&gt;

&lt;p&gt;e.g.&#160;sending this command via the shell&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;   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;{configureFailPoint: &quot;failCommand&quot;, mode: {times: 1}, data: { failCommands: [&quot;insert&quot;], writeConcernError: { code: NumberLong(91) } } }&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;when triggered, will return something like &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;   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;{ ..., writeConcernError: { code: NumberLong(91) }, ... }&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;By default, I believe the shell interprets numbers as Doubles, so just a vanilla untyped configureFailPoint shell command will have the code returned as a double. Specifying the code as NumberInt(..) is currently the only way to have libmongoc parse it correctly.&lt;/p&gt;</comment>
                            <comment id="2294609" author="kevin.albertson" created="Mon, 24 Jun 2019 13:47:04 +0000"  >&lt;p&gt;Thanks for investigating this. You&apos;re correct in that the code in _parse_error_reply is limiting the error code check to an int32 reply. It seems we&apos;ve been doing this as far back as 1.3:&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/blob/r1.3/src/mongoc/mongoc-rpc.c#L754-L757&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-c-driver/blob/r1.3/src/mongoc/mongoc-rpc.c#L754-L757&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;We don&apos;t catch this in retryable writes tests because it seems that using a failpoint to mock the error server reply always returns the error codes as int32 as well. So how did you encounter this bug? Did you see this on a live mongod returning the error code as a double?&lt;/p&gt;

&lt;p&gt;I have a couple other open questions that I should answer before completing this ticket.&lt;/p&gt;

&lt;p&gt;1. If we do should check for any numeric error code type, does this warrant a spec change in retryable writes, and other specs that mention error codes, to mention this?&lt;br/&gt;
2. Though this may be an isolated case, should configureFailPoint use the type of the error code provided, instead of always returning int32? Then we could have a spec test that validates different error code types.&lt;/p&gt;</comment>
                            <comment id="2240657" author="patrick.freed" created="Thu, 9 May 2019 21:29:48 +0000"  >&lt;p&gt;The cause of this is in mongo-rpc.c around line 1112, in &lt;tt&gt;_parse_error_reply&lt;/tt&gt;. When parsing write concern errors, this function expects the error code to be an &lt;tt&gt;int32.&lt;/tt&gt;&#160;When encountering non-&lt;tt&gt;int32&lt;/tt&gt; s, it ignores the code and reports no error.&lt;/p&gt;

&lt;p&gt;In the above example (where the error is caused by setting a failpoint in the shell), the code is sent back from the server as a double, so we see the bad behavior. Likewise, specifying the failpoint code using &lt;tt&gt;NumberLong(91)&lt;/tt&gt; also causes the write concern error to not be reported. Configuring with &lt;tt&gt;NumberInt(91)&lt;/tt&gt;&#160;produces the desired behavior, however.&lt;/p&gt;</comment>
                            <comment id="2240529" author="patrick.freed" created="Thu, 9 May 2019 20:22:45 +0000"  >&lt;p&gt;It also appears that the write concern error will be present in the reply even if the write is retried and succeeds on the second attempt. The function will report success via the return value (not the reply) regardless of whether the write was retried successfully or not, though.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </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_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hwfh73:</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>