<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 04:34:23 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-33727] Do not wait for write concern if opTime didn&apos;t change during write</title>
                <link>https://jira.mongodb.org/browse/SERVER-33727</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;If a command accepts a write concern, it will always call waitForWriteConcern, no matter if and how it fails. The only question is what OpTime it waits for. If no write was attempted (and consequently the GlobalLockAcquisitionTracker did not move forward the client opTime), we will simply wait for write concern on the client opTime from before the command began. The client opTime may be null, in which case we don&apos;t do any waiting, or may already be committed in which we also do no waiting: &lt;a href=&quot;https://github.com/mongodb/mongo/blob/0bc90017e2563ed7432d56051483763c91d28025/src/mongo/db/service_entry_point_mongod.cpp#L77-L88&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/blob/0bc90017e2563ed7432d56051483763c91d28025/src/mongo/db/service_entry_point_mongod.cpp#L77-L88&lt;/a&gt;&lt;br/&gt;
If there was a previous uncommitted write on the client, however, we end up waiting for write concern on the previous write, even if the current command received a parse error and should do no waiting. Alternatively, if that previous write was in a previous term, waitForWriteConcern will fail here instead of waiting on it or skipping waiting entirely: &lt;a href=&quot;https://github.com/mongodb/mongo/blob/0bc90017e2563ed7432d56051483763c91d28025/src/mongo/db/repl/replication_coordinator_impl.cpp#L1489-L1496&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/blob/0bc90017e2563ed7432d56051483763c91d28025/src/mongo/db/repl/replication_coordinator_impl.cpp#L1489-L1496&lt;/a&gt;. In the case where no write was even attempted, rather than wait on the previous write, we should not call waitForWriteConcern at all and just return early. This will prevent waiting on previous writes when unnecessary and failing commands unnecessarily when they shouldn&apos;t need to wait for write concern at all.&lt;/p&gt;

&lt;p&gt;There is an assumption here that if we do not attempt to take the GlobalLock at any point then we should not wait for write concern at all. This is not always true, such as with retryable writes retrying successful operations(&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33475&quot; title=&quot;Retried findAndModify doesn&amp;#39;t properly wait for writeConcern&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33475&quot;&gt;&lt;del&gt;SERVER-33475&lt;/del&gt;&lt;/a&gt;), in which case those commands should push the client OpTime forwards themselves to ensure we wait on the proper opTime.&lt;/p&gt;</description>
                <environment></environment>
        <key id="507264">SERVER-33727</key>
            <summary>Do not wait for write concern if opTime didn&apos;t change during write</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="james.wahlin@mongodb.com">James Wahlin</assignee>
                                    <reporter username="judah.schvimer@mongodb.com">Judah Schvimer</reporter>
                        <labels>
                            <label>neweng</label>
                    </labels>
                <created>Wed, 7 Mar 2018 19:01:31 +0000</created>
                <updated>Sun, 29 Oct 2023 22:34:02 +0000</updated>
                            <resolved>Thu, 23 May 2019 14:16:43 +0000</resolved>
                                                    <fixVersion>4.1.12</fixVersion>
                                    <component>Replication</component>
                                        <votes>1</votes>
                                    <watches>15</watches>
                                                                                                                <comments>
                            <comment id="2257767" author="xgen-internal-githook" created="Thu, 23 May 2019 14:13:35 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;james@mongodb.com&apos;, &apos;name&apos;: &apos;James Wahlin&apos;, &apos;username&apos;: &apos;jameswahlin&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33727&quot; title=&quot;Do not wait for write concern if opTime didn&amp;#39;t change during write&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33727&quot;&gt;&lt;del&gt;SERVER-33727&lt;/del&gt;&lt;/a&gt; Do not wait for write concern if opTime didn&apos;t change during write&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/358c0af2fe875d6a768cf87d7ddfaeb3181f804a&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/358c0af2fe875d6a768cf87d7ddfaeb3181f804a&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2249812" author="charlie.swanson" created="Fri, 17 May 2019 01:11:42 +0000"  >&lt;p&gt;Amazing! Thank you so much everyone above! &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=james.wahlin&quot; class=&quot;user-hover&quot; rel=&quot;james.wahlin&quot;&gt;james.wahlin&lt;/a&gt; see above for some great context here. Also happy to catch up in-person. It looks like you have time to slot this into the upcoming sprint but let me know if you don&apos;t.&lt;/p&gt;</comment>
                            <comment id="2249689" author="jesse" created="Thu, 16 May 2019 22:15:35 +0000"  >&lt;p&gt;Acknowledged, Andy, I retract my objection. =)&lt;/p&gt;</comment>
                            <comment id="2249683" author="tess.avitabile" created="Thu, 16 May 2019 22:10:16 +0000"  >&lt;p&gt;Thanks, &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; and &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;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=charlie.swanson&quot; class=&quot;user-hover&quot; rel=&quot;charlie.swanson&quot;&gt;charlie.swanson&lt;/a&gt;, I think this work is now sufficiently well-defined that the Query team can take it on. My only recommendation is to avoid changing the behavior of getLastError, if possible.&lt;/p&gt;</comment>
                            <comment id="2249669" author="schwerin" created="Thu, 16 May 2019 21:56:29 +0000"  >&lt;p&gt;I believe that step 5 of Judah&apos;s proposal (if a global write lock was acquired, still wait for replication) makes the scenario described by  Jesse and Shane above safe. Client A does need the guarantee that the acknowledgement in example step 3 above means the database state won&apos;t roll back.&lt;/p&gt;</comment>
                            <comment id="2249614" author="jesse" created="Thu, 16 May 2019 21:22:21 +0000"  >&lt;p&gt;I talked this over with &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;. On the one hand, we have no specific knowledge as Driver Team people that makes us say this is a bad idea. But we did think of a scenario that makes us concerned about this change.&lt;/p&gt;

&lt;p&gt;Years ago we knew of customers who would stream unacknowledged writes followed by a GLE, like Andy describes. Mongos broke that knowingly when it changed some connection pool logic, and drivers broke it similarly soon after. (Java and Python removed &quot;thread affinity&quot; from their pools.) So we think drivers don&apos;t support this technique anymore and applications have adapted.&lt;/p&gt;

&lt;p&gt;Still, it seems like Judah&apos;s proposed change might not be a good idea. Consider:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Client A updates a document with {$set: {x: 1}} and w: majority.&lt;/li&gt;
	&lt;li&gt;Client B races to also update the document with {$set: {x: 1}}.&lt;/li&gt;
	&lt;li&gt;Client A receives w: majority acknowledgement.&lt;/li&gt;
	&lt;li&gt;The primary crashes.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Today, Client A knows that x was set to 1 and won&apos;t be rolled back, no matter whether Client A or Client B won the race. But&#160;it seems to us that after the proposed change, Client A loses this guarantee. Users would lose this simple technique to do an update and know the durable outcome.&lt;/p&gt;</comment>
                            <comment id="2245130" author="schwerin" created="Mon, 13 May 2019 20:59:21 +0000"  >&lt;p&gt;Well, once upon a time, it mattered. I don&apos;t know if it still should. The use case was that clients would send a sequence of fire-and-forget writes and then do gLE at the end. Since we hung up on connections on step-down, a successful gLE would guarantee that all prior writes had committed. I don&apos;t know that we promised that the combined write+gle of using a write command counted in the same way. I also don&apos;t know if we should preserve that behavior even if we used to leverage it. It hasn&apos;t been a guarantee preserved by sharding for at least 4 years, and I suspect that it wasn&apos;t correctly preserved before then.&lt;/p&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;, could you think about this for 10 minutes and weigh in?&lt;/p&gt;</comment>
                            <comment id="2244220" author="tess.avitabile" created="Mon, 13 May 2019 13:41:30 +0000"  >&lt;p&gt;That&apos;s a good point, we will need to make sure this change does not affect the behavior of getLastError.&lt;/p&gt;

&lt;p&gt;However, I was particularly asking whether&#160;we have any implicit guarantee that a successful majority writeConcern implies that all previous operations performed by the client are majority committed. That is, supposing aggregate now always accepts a writeConcern, should a successful aggregate with writeConcern w:majority (that did not attempt to write) imply that all previous operations performed by the client are majority committed?&lt;/p&gt;</comment>
                            <comment id="2240700" author="schwerin" created="Thu, 9 May 2019 21:56:08 +0000"  >&lt;p&gt;Ugh, this is really hard to answer. The getLastError command is still supported and may not take a write lock? Even if it doesn&apos;t, I&apos;m not sure if all commands that choose to not write do so having already taken a write lock.&lt;/p&gt;</comment>
                            <comment id="2240627" author="tess.avitabile" created="Thu, 9 May 2019 21:09:33 +0000"  >&lt;p&gt;Got it, thanks. I&#160;&lt;em&gt;think&lt;/em&gt; this will be okay. My only concern is whether we have any implicit guarantee that a successful majority writeConcern implies that all previous operations performed by the client are majority committed. We might make that implicit guarantee in order to provide feature parity with getLastError. &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;, do you believe we are making this implicit guarantee today?&lt;/p&gt;</comment>
                            <comment id="2240555" author="judah.schvimer" created="Thu, 9 May 2019 20:35:38 +0000"  >&lt;p&gt;My proposal is slightly different than what we do today. Today we wait for write concern no matter what. In my proposal, if both (1) &lt;tt&gt;lastOpAfterRun == lastOpBeforeRun&lt;/tt&gt; and (2) we did not take a global write lock, then we would not wait for write concern.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;If lastOpBeforeRun was not committed and the writeConcern is majority, then we will wait for this OpTime to be committed.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Today I agree. If we did not wait for write concern when both (1) &lt;tt&gt;lastOpAfterRun == lastOpBeforeRun&lt;/tt&gt; and (2) we did not take a global write lock, then this would no longer be the case.&lt;/p&gt;</comment>
                            <comment id="2240364" author="tess.avitabile" created="Thu, 9 May 2019 18:59:27 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=judah.schvimer&quot; class=&quot;user-hover&quot; rel=&quot;judah.schvimer&quot;&gt;judah.schvimer&lt;/a&gt;, I think your proposal is &lt;a href=&quot;https://github.com/mongodb/mongo/blob/204352fb65123323bb50800741b1b322fe648f15/src/mongo/db/service_entry_point_mongod.cpp#L107-L123&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;how the code works today&lt;/a&gt;.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;This means that if lastOpAfterRun == lastOpBeforeRun and we did not take a global write lock at all we would not wait for write concern.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I don&apos;t think this is true. If &lt;tt&gt;lastOpBeforeRun&lt;/tt&gt; was not committed and the writeConcern is majority, then we will wait for this OpTime to be committed. I think we would need to take additional action to skip the wait for writeConcern if &lt;tt&gt;lastOpAfterRun == lastOpBeforeRun&lt;/tt&gt;.&lt;/p&gt;</comment>
                            <comment id="2240336" author="judah.schvimer" created="Thu, 9 May 2019 18:44:52 +0000"  >&lt;p&gt;The proposal is that we would do the following:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;get the client&apos;s &lt;tt&gt;lastOp&lt;/tt&gt; before running the command: &lt;tt&gt;lastOpBeforeRun&lt;/tt&gt;&lt;/li&gt;
	&lt;li&gt;run the command&lt;/li&gt;
	&lt;li&gt;get the client&apos;s &lt;tt&gt;lastOp&lt;/tt&gt; after running the command: &lt;tt&gt;lastOpAfterRun&lt;/tt&gt;&lt;/li&gt;
	&lt;li&gt;if &lt;tt&gt;lastOpAfterRun != lastOpBeforeRun&lt;/tt&gt;, wait for write concern on &lt;tt&gt;lastOpAfterRun&lt;/tt&gt;&lt;/li&gt;
	&lt;li&gt;if &lt;tt&gt;lastOpAfterRun == lastOpBeforeRun&lt;/tt&gt; and a global write lock was taken, bump forward the client&apos;s &lt;tt&gt;lastOp&lt;/tt&gt; to the system&apos;s last optime and wait for write concern on the client&apos;s new &lt;tt&gt;lastOp&lt;/tt&gt;&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;This means that if &lt;tt&gt;lastOpAfterRun == lastOpBeforeRun&lt;/tt&gt; and we did not take a global write lock at all we would not wait for write concern. &lt;/p&gt;

&lt;p&gt;One concern here is if the system&apos;s last optime is equal to &lt;tt&gt;lastOpBeforeRun&lt;/tt&gt; and we want to wait for write concern on a successful retryable write. An addendum to the above would be to track when we&apos;ve set the client&apos;s &lt;tt&gt;lastOp&lt;/tt&gt; explicitly in the current operation and wait for write concern no matter what in that case.&lt;/p&gt;

&lt;p&gt;Alternatively, we could just not wait for write concern if &lt;tt&gt;lastOpAfterRun == lastOpBeforeRun&lt;/tt&gt;, the global write lock was not taken, and &lt;tt&gt;lastOpAfterRun&apos;s&lt;/tt&gt; term doesn&apos;t match the current term.&lt;/p&gt;</comment>
                            <comment id="2240212" author="tess.avitabile" created="Thu, 9 May 2019 17:15:41 +0000"  >&lt;p&gt;I&apos;m confused about the proposed solution. My understanding is that we would only wait for writeConcern if the command took a write lock, and that we would have retryable writes push the client OpTime forward when retrying a successful operation. However, I don&apos;t see how this would ensure we wait for writeConcern on retryable writes when retrying a successful operation, since they do not take write locks. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=judah.schvimer&quot; class=&quot;user-hover&quot; rel=&quot;judah.schvimer&quot;&gt;judah.schvimer&lt;/a&gt;, can you clarify this?&lt;/p&gt;</comment>
                            <comment id="2239065" author="charlie.swanson" created="Wed, 8 May 2019 20:20:20 +0000"  >&lt;p&gt;This ticket may have just become a priority for the query team. As part of adding $merge, the drivers team is interested to see if we can update the server&apos;s contract so that all aggregates accept both readConcern and writeConcern. This will allow both server and drivers to remove &lt;a href=&quot;https://github.com/mongodb/mongo/blob/ba825c452525fb6fa7e28196cc84a49809b6f4be/src/mongo/db/commands/pipeline_command.cpp#L76&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;some special-casing for the $out stage&lt;/a&gt;, and avoid adding some new special-casing for $merge. If we allow every aggregate to accept a writeConcern, we don&apos;t want the read-only aggregates to wait for the previous operation&apos;s write concern.&lt;/p&gt;

&lt;p&gt;Based on this ticket it sounds like there are no known problems with implementing this, and the code changes look relatively straightforward. Would anyone mind if the query team took this on and sent to replication for review? Please let me know if you foresee any problems.&lt;/p&gt;

&lt;p&gt;cc &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;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jeff.yemin&quot; class=&quot;user-hover&quot; rel=&quot;jeff.yemin&quot;&gt;jeff.yemin&lt;/a&gt; and &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;/p&gt;</comment>
                            <comment id="1827208" author="schwerin" created="Thu, 8 Mar 2018 14:31:07 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=judah.schvimer&quot; class=&quot;user-hover&quot; rel=&quot;judah.schvimer&quot;&gt;judah.schvimer&lt;/a&gt;, could you clarify the description and summary a little. It fooled &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=milkie&quot; class=&quot;user-hover&quot; rel=&quot;milkie&quot;&gt;milkie&lt;/a&gt; and I.&lt;/p&gt;</comment>
                            <comment id="1826518" author="milkie" created="Wed, 7 Mar 2018 20:23:02 +0000"  >&lt;p&gt;SGTM&lt;/p&gt;</comment>
                            <comment id="1826492" author="judah.schvimer" created="Wed, 7 Mar 2018 20:02:52 +0000"  >&lt;p&gt;The GlobalLockAcquisionTracker added in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-27067&quot; title=&quot;Some Commands do not wait for write concern for no-op writes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-27067&quot;&gt;&lt;del&gt;SERVER-27067&lt;/del&gt;&lt;/a&gt;, still tracks when we attempt to take a global lock, which shows when we attempt to do a write. &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-27067&quot; title=&quot;Some Commands do not wait for write concern for no-op writes&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-27067&quot;&gt;&lt;del&gt;SERVER-27067&lt;/del&gt;&lt;/a&gt; assumes that no-op writes always attempt to take a global lock. Things like retryable writes that break that contract, need to set the client optime themselves.&lt;/p&gt;</comment>
                            <comment id="1826461" author="milkie" created="Wed, 7 Mar 2018 19:39:35 +0000"  >&lt;p&gt;How are you going to tell the difference between &quot;a parse error that should do no waiting&quot; and &quot;a no-op write that should wait&quot;?  For example, a non-parse error for which we still need to wait would be a duplicate key error; we need to wait in order to ensure the client can do a subsequent read and see the data that caused the duplicate key error.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10320">
                    <name>Documented</name>
                                                                <inwardlinks description="is documented by">
                                        <issuelink>
            <issuekey id="775320">DOCS-12750</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="495667">SERVER-33232</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="501848">SERVER-33475</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="332329">SERVER-27067</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>19.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10038"><![CDATA[Fully Compatible]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 7 Mar 2018 19:39:35 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        4 years, 37 weeks, 6 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_10857" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>PM-1396</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>false</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>
                            4 years, 37 weeks, 6 days ago
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_16465" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Linked BF Score</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>50.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10026"><![CDATA[ALL]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>jesse@mongodb.com</customfieldvalue>
            <customfieldvalue>schwerin@mongodb.com</customfieldvalue>
            <customfieldvalue>charlie.swanson@mongodb.com</customfieldvalue>
            <customfieldvalue>milkie@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>james.wahlin@mongodb.com</customfieldvalue>
            <customfieldvalue>judah.schvimer@mongodb.com</customfieldvalue>
            <customfieldvalue>tess.avitabile@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|htrz0v:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hr7kwf:</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="2843">Query 2019-06-03</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|htrl7j:</customfieldvalue>

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