<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 04:34:14 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-33683] Allow aggregation $mergeCursors stage to run inside a transaction</title>
                <link>https://jira.mongodb.org/browse/SERVER-33683</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;We banned aggregations within transactions on mongos as part of &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33660&quot; title=&quot;Once getMores include lsid, sharded aggregations with $mergeCursors can hang&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33660&quot;&gt;&lt;del&gt;SERVER-33660&lt;/del&gt;&lt;/a&gt;, because doing so could potentially cause a deadlock. We should investigate how to perform a $mergeCursors against the same shard without inducing a deadlock. One idea is to avoid going over the network for a local cursor.&lt;/p&gt;</description>
                <environment></environment>
        <key id="506070">SERVER-33683</key>
            <summary>Allow aggregation $mergeCursors stage to run inside a transaction</summary>
                <type id="4" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14710&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="13201">Fixed</resolution>
                                        <assignee username="ian.boros@mongodb.com">Ian Boros</assignee>
                                    <reporter username="charlie.swanson@mongodb.com">Charlie Swanson</reporter>
                        <labels>
                    </labels>
                <created>Mon, 5 Mar 2018 22:08:18 +0000</created>
                <updated>Sun, 29 Oct 2023 22:34:06 +0000</updated>
                            <resolved>Mon, 17 Dec 2018 22:39:22 +0000</resolved>
                                                    <fixVersion>4.1.7</fixVersion>
                                    <component>Aggregation Framework</component>
                    <component>Sharding</component>
                                        <votes>0</votes>
                                    <watches>13</watches>
                                                                                                                <comments>
                            <comment id="2093557" author="xgen-internal-githook" created="Mon, 17 Dec 2018 21:38:43 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;ian.boros@10gen.com&apos;, &apos;name&apos;: &apos;Ian Boros&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33683&quot; title=&quot;Allow aggregation $mergeCursors stage to run inside a transaction&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33683&quot;&gt;&lt;del&gt;SERVER-33683&lt;/del&gt;&lt;/a&gt; Prevent deadlock in aggregate with transactions&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/d40d24abc025690150ccf8009ba1facb9ed1c6b2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/d40d24abc025690150ccf8009ba1facb9ed1c6b2&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2075309" author="kaloian.manassiev" created="Thu, 29 Nov 2018 13:51:30 +0000"  >&lt;p&gt;I agree that checking-in the session should also stash the resources - sorry I missed this while working on the dependent &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37665&quot; title=&quot;Add interface to check in and check out sessions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37665&quot;&gt;&lt;del&gt;SERVER-37665&lt;/del&gt;&lt;/a&gt;. Basically at the point where you decide to relinquish control of that thread to the remote node, the calling thread should start looking as if it returned from a &lt;tt&gt;getMore&lt;/tt&gt; and be completely &quot;pristine&quot;. So yes, &lt;a href=&quot;https://github.com/mongodb/mongo/blob/01d25f74348e8594e96a9e01dfca60538677d078/src/mongo/db/service_entry_point_common.cpp#L401&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;this is&lt;/a&gt; how this should work. This logic should be on top of the &lt;tt&gt;OperationContextSession&lt;/tt&gt; - baked in the &lt;a href=&quot;https://github.com/mongodb/mongo/blob/01d25f74348e8594e96a9e01dfca60538677d078/src/mongo/db/session_catalog_mongod.cpp#L177&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;&lt;tt&gt;MongoDOperationContextSession&lt;/tt&gt;&lt;/a&gt;, which should also expose a check-in/check-out methods.&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;some other operation could start running under the same transaction before the getMore has a chance to check out the session &lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;The &lt;a href=&quot;https://docs.google.com/document/d/1Tj2zi29wVWh4N0Co0I6AkFHXxcUdG1PWWkQbDMU4Nb8/edit#heading=h.vqhtj2owrwcj&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;original proposal&lt;/a&gt; had suggested also keeping a track of a sub-session token, so that only branches from the same invocation can check it out. This means a significant change to the networking protocol though and we decided not to do it just in order to counteract misbehaved client.&lt;/p&gt;</comment>
                            <comment id="2074692" author="charlie.swanson" created="Wed, 28 Nov 2018 22:20:35 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=ian.boros&quot; class=&quot;user-hover&quot; rel=&quot;ian.boros&quot;&gt;ian.boros&lt;/a&gt; while the case you describe is indeed worrisome, I can&apos;t think of anything great we could do to prevent it, and I believe it would already be a problem with something like an ordered bulk write operation through mongos. I think we will just have to be careful that we don&apos;t write any invariants that depend on well-behaved clients. This also came up during initial discussions with &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kaloian.manassiev&quot; class=&quot;user-hover&quot; rel=&quot;kaloian.manassiev&quot;&gt;kaloian.manassiev&lt;/a&gt; and we couldn&apos;t think of a great way around this.&lt;/p&gt;</comment>
                            <comment id="2074503" author="ian.boros" created="Wed, 28 Nov 2018 20:16:28 +0000"  >&lt;p&gt;Oh, James Wahlin (not tagging) just made a really insightful point: Assuming we take the above approach, there&apos;s a possibility that while the $mergeCursors is blocking (with the transaction resources stashed), some other operation could start running under the same transaction before the &lt;tt&gt;getMore&lt;/tt&gt; has a chance to check out the session (this might require a poorly-behaved driver). I imagine this could break a lot of things.&lt;/p&gt;</comment>
                            <comment id="2074490" author="ian.boros" created="Wed, 28 Nov 2018 20:04:23 +0000"  >&lt;p&gt;After looking into this ticket, having an operation yield its session while it blocks won&apos;t be enough to make this work. After an operation running $mergeCursors yields its session and blocks, the operation running&#160;&lt;tt&gt;getMore&lt;/tt&gt;&#160;(on the same node) will check the session out, but then realize that the transaction is already in progress, though no resources have been stashed (they&apos;re still in use by the aggregation running $mergeCursors). This causes it to &lt;a href=&quot;https://github.com/mongodb/mongo/blob/ac6d01aeea9a7ee989b7d1bc879d25e18c5b32a6/src/mongo/db/transaction_participant.cpp#L323-L337&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;abort the transaction&lt;/a&gt;. To get around this, I believe $mergeCursors will also have to stash its transaction resources while it blocks on the remote requests, and unstash them when it resumes. This way, the &lt;tt&gt;getMore&lt;/tt&gt; will find (and unstash) the resources once it checks out the session. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kaloian.manassiev&quot; class=&quot;user-hover&quot; rel=&quot;kaloian.manassiev&quot;&gt;kaloian.manassiev&lt;/a&gt; Does this seem reasonable?&lt;/p&gt;

&lt;p&gt;CC &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;&lt;/p&gt;</comment>
                            <comment id="2017830" author="charlie.swanson" created="Fri, 28 Sep 2018 17:29:12 +0000"  >&lt;p&gt;This impacts a wide variety of aggregations that can be run. Anything involving a $lookup or $graphLookup, anything which uses allowDiskUse: true in combination with a $sort or $group, and possibly some other cases. I can&apos;t give you an estimate on what percentage of aggregations this would be, but my guess would be at least 10%. These cases aren&apos;t that outlandish. Once again, the impact here is that these aggregations would not be able to be run within a transaction - I have no idea how common that would be. It seems like a strange, surprising, and undesirable restriction to have to me, so I certainly think it should be at least 4.1 Required - I can&apos;t say which epic it would be in.&lt;/p&gt;</comment>
                            <comment id="2017236" author="kaloian.manassiev" created="Fri, 28 Sep 2018 07:51:45 +0000"  >&lt;p&gt;Yes, that&apos;s what I was looking for, thanks Jack.&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;, do you mind summarizing what are the customer-visible limitations if we were to leave shard merging disabled in 4.2 when you get a chance? I want to make sure we don&apos;t forget to do that as part of the final sharding support Epic or if we think it is not that important we should make it 4.1 Desired.&lt;/p&gt;</comment>
                            <comment id="2017141" author="jack.mulrow" created="Fri, 28 Sep 2018 03:40:25 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kaloian.manassiev&quot; class=&quot;user-hover&quot; rel=&quot;kaloian.manassiev&quot;&gt;kaloian.manassiev&lt;/a&gt;, &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=misha.tyulenev&quot; class=&quot;user-hover&quot; rel=&quot;misha.tyulenev&quot;&gt;misha.tyulenev&lt;/a&gt; added &lt;a href=&quot;https://github.com/mongodb/mongo/blob/b0844bec95/src/mongo/s/query/cluster_aggregate.cpp#L999-L1004&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;this uassert in ClusterAggregate&lt;/a&gt;&#160;in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33029&quot; title=&quot;Support snapshot in cluster aggregate command&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33029&quot;&gt;&lt;del&gt;SERVER-33029&lt;/del&gt;&lt;/a&gt; to disallow sending a merging pipeline to a shard in a transaction - is that what you&apos;re looking for?&#160;&lt;/p&gt;</comment>
                            <comment id="2015954" author="kaloian.manassiev" created="Thu, 27 Sep 2018 09:12:04 +0000"  >&lt;p&gt;Thanks for the detailed explanation &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; and sorry for the late reply.&lt;/p&gt;

&lt;p&gt;Currently, sharded &lt;tt&gt;$lookup&lt;/tt&gt; with transactions is not in the scope of PM-834, but it looks like other aggregation scenarios, which involve &lt;tt&gt;$mergeCursors&lt;/tt&gt; will not work either. I have no idea what is the importance of these scenarios from usability point of view - do you mind explaining that to me? I am trying to decide whether this ticket should remain in the current Epic, move to the final transactions support Epic (PM-564) or we can just make it 4.1 Desired and we get to it, if we get to it.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jack.mulrow%40mongodb.com&quot; class=&quot;user-hover&quot; rel=&quot;jack.mulrow@mongodb.com&quot;&gt;jack.mulrow@mongodb.com&lt;/a&gt;, I remember in 4.0 we did something to disable these scenarios, but I couldn&apos;t find the associated tickets or commits. Can you remind me what did we do to disable them?&lt;/p&gt;</comment>
                            <comment id="1983893" author="charlie.swanson" created="Thu, 23 Aug 2018 15:26:32 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=kaloian.manassiev&quot; class=&quot;user-hover&quot; rel=&quot;kaloian.manassiev&quot;&gt;kaloian.manassiev&lt;/a&gt; we have not officially designed or written down an approach for anything. This ticket is not necessarily tied to the sharded $lookup epic - since this is a problem today. The sharded $lookup project will introduce another similar scenario to this one - but I&apos;ll get back to that later.&lt;/p&gt;

&lt;p&gt;The problem for this ticket is more of a self-deadlock within one shard on the state associated with the transaction. It does not necessarily involve a $lookup. If you run the aggregation &lt;span class=&quot;error&quot;&gt;&amp;#91;\{$group: {_id: &amp;quot;anything&amp;quot;}}&amp;#93;&lt;/span&gt;, with {allowDiskUse: true}, it will perform a partial group on each shard, then the &quot;group of groups&quot; on a designated merging shard. That merging shard can now have two simultaneous operations going on in the same transaction. First, the operation performing the merge to compute the &quot;group of groups&quot;; This operation will be merging multiple cursors from every shard with chunks for the collection, one of which may be itself. Second, the operation computing the sub-group from this shard. While the first operation is running, it will at some point schedule a getMore on a cursor which the same shard owns.&#160;I don&apos;t recall all the details, but I think the &lt;tt&gt;Session&lt;/tt&gt;&#160;object has to be &quot;checked out&quot; for a transaction, and could only be checked out by one operation. The first operation would check it out, schedule the getMore, then the getMore would be blocked waiting for it to be checked back in - which it never could be until the getMore returned.&lt;/p&gt;

&lt;p&gt;Today (in a world without sharded $lookup), we could pursue a fix for this ticket which would avoid sending network requests to ourselves to perform that merge. This would essentially avoid going back through the top of command processing which will attempt to check out the transaction state. It will take a refactor to the AsyncResultsMerger to do so, since the AsyncResultsMerger only knows how to merge cursors which have IDs and can be iterated with getMore commands - but it seems possible.&lt;/p&gt;

&lt;p&gt;However, when we start to think about sharded $lookup - we will be able to get into a scenario where two operations are happening simultaneously on one shard as part of the same transaction - and there will be no real way to avoid it. It&apos;s a little complicated to set up, but you could end up with a pipeline where one shard can be doing a $lookup which goes to a remote shard, which then has to do a $lookup again and goes back to the original shard. In order to support this scenario, the fix would likely have to involve having the ability to have multiple operations use the same &lt;tt&gt;Session&lt;/tt&gt; object at once.&lt;/p&gt;</comment>
                            <comment id="1983609" author="kaloian.manassiev" created="Thu, 23 Aug 2018 11:26:45 +0000"  >&lt;p&gt;Now that the sharded transactions work is coming along, I would like to get back to this ticket and to see how we can meaningfully get &lt;tt&gt;$lookup&lt;/tt&gt; to work with sharded transactions.&lt;/p&gt;

&lt;p&gt;Have you guys considered this as part of the Sharded $lookup project and what it would take to fix it? Is it just the local shard which is a problem or also there was a case where a request from a different shard could come back?&lt;/p&gt;

&lt;p&gt;To: &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;, &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;&lt;br/&gt;
CC &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jack.mulrow&quot; class=&quot;user-hover&quot; rel=&quot;jack.mulrow&quot;&gt;jack.mulrow&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1843339" author="charlie.swanson" created="Fri, 23 Mar 2018 15:31:04 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=misha.tyulenev&quot; class=&quot;user-hover&quot; rel=&quot;misha.tyulenev&quot;&gt;misha.tyulenev&lt;/a&gt; we&apos;d like to have a discussion with the query team about how to fix this, but depending on the approach any engineer could work on this.&lt;/p&gt;</comment>
                            <comment id="1826192" author="misha.tyulenev" created="Wed, 7 Mar 2018 16:50:54 +0000"  >&lt;p&gt;Thanks Charlie, thats correct. &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33029&quot; title=&quot;Support snapshot in cluster aggregate command&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33029&quot;&gt;&lt;del&gt;SERVER-33029&lt;/del&gt;&lt;/a&gt; will establish a global snapshot logicalTime that is most likely to be valid and send an aggregate to the individual shards.&lt;/p&gt;</comment>
                            <comment id="1826061" author="david.storch" created="Wed, 7 Mar 2018 16:01:50 +0000"  >&lt;p&gt;Yes, helpful, thanks for the clarification. I&apos;ll retitle the ticket to help clarify this.&lt;/p&gt;</comment>
                            <comment id="1825969" author="charlie.swanson" created="Wed, 7 Mar 2018 15:25:25 +0000"  >&lt;p&gt;I think these are separate work items, but &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33029&quot; title=&quot;Support snapshot in cluster aggregate command&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33029&quot;&gt;&lt;del&gt;SERVER-33029&lt;/del&gt;&lt;/a&gt; depends on this one. There is independent work (what I believe is described in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33029&quot; title=&quot;Support snapshot in cluster aggregate command&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33029&quot;&gt;&lt;del&gt;SERVER-33029&lt;/del&gt;&lt;/a&gt;) to compute which snapshot to use cluster-wide, then append that snapshot into each command. Separately, we need to somehow modify the $mergeCursors story to avoid confusing/deadlocking itself, which is what&apos;s tracked in this ticket. I have some ideas of how to do this ticket, I have very little information (personally) about how to do &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33029&quot; title=&quot;Support snapshot in cluster aggregate command&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33029&quot;&gt;&lt;del&gt;SERVER-33029&lt;/del&gt;&lt;/a&gt;. Does that help?&lt;/p&gt;</comment>
                            <comment id="1825955" author="david.storch" created="Wed, 7 Mar 2018 15:18:45 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=misha.tyulenev&quot; class=&quot;user-hover&quot; rel=&quot;misha.tyulenev&quot;&gt;misha.tyulenev&lt;/a&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;, we may have to coordinate on this. It&apos;s not clear to me how this is different from &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-33029&quot; title=&quot;Support snapshot in cluster aggregate command&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-33029&quot;&gt;&lt;del&gt;SERVER-33029&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                        <issuelink>
            <issuekey id="621627">SERVER-37665</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is depended on by">
                                        <issuelink>
            <issuekey id="617734">SERVER-37619</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="514179">SERVER-34015</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="614827">SERVER-37499</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="1998541">SERVER-64407</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="505762">SERVER-33660</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="489883">SERVER-33029</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="503563">SERVER-33541</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>16.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>3.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 15:18:45 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        5 years, 8 weeks, 2 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[<s><a href='https://jira.mongodb.org/browse/SERVER-37665'>SERVER-37665</a></s>]]></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-1294</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>luke.bonanomi@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            5 years, 8 weeks, 2 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>charlie.swanson@mongodb.com</customfieldvalue>
            <customfieldvalue>david.storch@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>ian.boros@mongodb.com</customfieldvalue>
            <customfieldvalue>jack.mulrow@mongodb.com</customfieldvalue>
            <customfieldvalue>kaloian.manassiev@mongodb.com</customfieldvalue>
            <customfieldvalue>misha.tyulenev@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|htrrpz:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hu685b:</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="2536">Query 2018-12-03</customfieldvalue>
    <customfieldvalue id="2572">Query 2018-12-17</customfieldvalue>
    <customfieldvalue id="2594">Query 2018-12-31</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|htrdwf:</customfieldvalue>

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