<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 05:05:29 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-44260] Transaction can conflict with previous transaction on the session if the all committed point is held back</title>
                <link>https://jira.mongodb.org/browse/SERVER-44260</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;After &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-38028&quot; title=&quot;Participant with prepared transaction on session should block request for higher txn number on session rather than failing the new request&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-38028&quot;&gt;&lt;del&gt;SERVER-38028&lt;/del&gt;&lt;/a&gt;, participants block requests for higher txn numbers instead of failing them. So, a transaction started with read concern snapshot following a prepared transaction could have its read timestamp held back due to oplog holes (since the read timestamp will be set to the &lt;a href=&quot;https://github.com/mongodb/mongo/blob/c801d7cca46f020a08d38e0e541d8e981b8649e0/src/mongo/db/transaction_participant.cpp#L590-L598&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;all committed point&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The following scenario describes the bug:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Thread 1 prepares txn0 at time 5&lt;/li&gt;
	&lt;li&gt;Thread 2 starts new txn1 that blocks on txn0 since it is on the same session&lt;/li&gt;
	&lt;li&gt;Thread 3 opens oplog hole at time 8&lt;/li&gt;
	&lt;li&gt;Thread 1 commits txn0 at time 6, but commit oplog entry (and txn table update) written at time 9&lt;/li&gt;
	&lt;li&gt;On thread 2, txn1 opens storage transaction at all_durable, which would be time 7 since there is an oplog hole at time 8&lt;/li&gt;
	&lt;li&gt;txn1 gets a write conflict when writing to the txn table bc it&apos;s reading from time 7 and doesn&apos;t see the write from time 9&lt;/li&gt;
&lt;/ul&gt;

</description>
                <environment></environment>
        <key id="979530">SERVER-44260</key>
            <summary>Transaction can conflict with previous transaction on the session if the all committed point is held back</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="pavithra.vetriselvan@mongodb.com">Pavithra Vetriselvan</assignee>
                                    <reporter username="samy.lanka@mongodb.com">Samyukta Lanka</reporter>
                        <labels>
                            <label>KP42</label>
                    </labels>
                <created>Fri, 25 Oct 2019 21:10:43 +0000</created>
                <updated>Sun, 29 Oct 2023 22:15:41 +0000</updated>
                            <resolved>Tue, 21 Jan 2020 20:06:26 +0000</resolved>
                                                    <fixVersion>4.2.4</fixVersion>
                    <fixVersion>4.3.3</fixVersion>
                                    <component>Replication</component>
                                        <votes>0</votes>
                                    <watches>12</watches>
                                                                                                                <comments>
                            <comment id="2748179" author="xgen-internal-githook" created="Tue, 21 Jan 2020 20:04:12 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;pavithra.vetriselvan@mongodb.com&apos;, &apos;name&apos;: &apos;Pavithra Vetriselvan&apos;, &apos;username&apos;: &apos;pvselvan&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-44260&quot; title=&quot;Transaction can conflict with previous transaction on the session if the all committed point is held back&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-44260&quot;&gt;&lt;del&gt;SERVER-44260&lt;/del&gt;&lt;/a&gt; New transaction should wait for previous txn table update to be in snapshot&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/41b3d7da7c763e304bc8f4056d0d31d200742e0b&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/41b3d7da7c763e304bc8f4056d0d31d200742e0b&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2722506" author="pavithra.vetriselvan" created="Mon, 13 Jan 2020 18:03:52 +0000"  >&lt;p&gt;This is just waiting for &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-45500&quot; title=&quot;Fix backport exclude logic from multiversion tests for new test files&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-45500&quot;&gt;&lt;del&gt;SERVER-45500&lt;/del&gt;&lt;/a&gt; to go in!&lt;/p&gt;</comment>
                            <comment id="2601867" author="pavithra.vetriselvan" created="Thu, 12 Dec 2019 16:11:52 +0000"  >&lt;p&gt;Yep, confirmed with sharding that the coordinator send &lt;tt&gt;commitTransaction&lt;/tt&gt; with &lt;tt&gt;w: majority&lt;/tt&gt;. &lt;/p&gt;

&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; and I investigated this yesterday and figured out that the test is running these transactions in parallel shells. Participants of a cross-shard transaction will block requests for higher txnNumbers (not fail them). In this scenario, the second transaction starts when the first exits prepare, not when it majority commits. This transaction can start while there is a hole, caused by some arbitrary parallel writer, behind the commit oplog entry. &lt;/p&gt;

&lt;p&gt;I&apos;ve updated the ticket description with a detailed scenario. Thanks Judah for the help!&lt;/p&gt;</comment>
                            <comment id="2599480" author="judah.schvimer" created="Wed, 11 Dec 2019 17:46:58 +0000"  >&lt;blockquote&gt;
&lt;p&gt;the prepared commit should be using w: majority, right?&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;The commit decision has to be majority committed, but the coordinator does not need to majority commit the &lt;tt&gt;commitTransaction&lt;/tt&gt; command on the participant. That said, the coordinator might choose to always do so, I am not sure.&lt;/p&gt;</comment>
                            <comment id="2599353" author="pavithra.vetriselvan" created="Wed, 11 Dec 2019 16:56:10 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=siyuan.zhou&quot; class=&quot;user-hover&quot; rel=&quot;siyuan.zhou&quot;&gt;siyuan.zhou&lt;/a&gt; &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=lingzhi.deng&quot; class=&quot;user-hover&quot; rel=&quot;lingzhi.deng&quot;&gt;lingzhi.deng&lt;/a&gt; That makes sense. Unfortunately, we don&apos;t have data files or a core dump from the BF where this behavior manifested. We do know that the first transaction was prepared though. Therefore, the prepared commit should be using &lt;tt&gt;w: majority&lt;/tt&gt;, right? We also know that the second transaction, whose commit caused the conflict, was not prepared. &lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;&quot;...it should have waited for the holes before its commit time.&quot;&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I&apos;m not sure I understand this statement.  If the update to the transactions table occurs at a different timestamp than the commit (since it is a separate write), isn&apos;t it still possible to reserve an oplog slot in between the two? If we made the transactions table write occur at the commitTS, then perhaps using &lt;tt&gt;w: majority&lt;/tt&gt; would fix this. &lt;/p&gt;</comment>
                            <comment id="2599252" author="judah.schvimer" created="Wed, 11 Dec 2019 16:12:51 +0000"  >&lt;p&gt;Since we use speculative behavior for snapshot read concern, I don&apos;t think we need to wait for the previous transactions table update to be in the committed snapshot. I think we just need the previous transactions table update to be earlier than the &lt;tt&gt;all_durable&lt;/tt&gt; timestamp. Calling &lt;tt&gt;waitForAllEarlierOplogWritesToBeVisible&lt;/tt&gt; would ensure this, but would slow down back to back transactions since that waits for the &lt;tt&gt;all_durable&lt;/tt&gt; timestamp to be greater than the latest timestamp in the oplog, which is a stronger condition than we need. &lt;/p&gt;

&lt;p&gt;Can the TransactionParticipant keep track of the timestamp of the most recent transactions table write? We could then give &lt;tt&gt;waitForAllEarlierOplogWritesToBeVisible&lt;/tt&gt; an optional timestamp to wait on instead of the latest timestamp in the oplog.&lt;/p&gt;</comment>
                            <comment id="2598882" author="jason.chan" created="Wed, 11 Dec 2019 15:27:18 +0000"  >&lt;p&gt;Note: We also have &lt;a href=&quot;https://github.com/mongodb/mongo/blob/79af378abece4049e2042cfcfcf2275aff7c3fb8/jstests/replsets/majority_writes_wait_for_all_durable_timestamp.js#L19&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;majority_writes_wait_for_all_durable_timestamp.js&lt;/a&gt; that tests that majority writes wait for the all committed (now called the all durable) timestamp on a single node replica set. This was initially added as part of &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-41769&quot; title=&quot;The committedSnapshot should not be greater than allCommitted when EMRC=false&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-41769&quot;&gt;&lt;del&gt;SERVER-41769&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="2598773" author="lingzhi.deng" created="Wed, 11 Dec 2019 14:57:09 +0000"  >&lt;p&gt;I think even on a single node replset, w: majority also waits for holes. This is because we &lt;a href=&quot;https://github.com/mongodb/mongo/blob/1bbb3a2b7752ca1c6c254e78494b945597a4c72b/src/mongo/db/repl/replication_coordinator_impl.cpp#L3695&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;set the committed snapshot to stable timestamp&lt;/a&gt; (or &lt;a href=&quot;https://github.com/mongodb/mongo/blob/1bbb3a2b7752ca1c6c254e78494b945597a4c72b/src/mongo/db/repl/replication_coordinator_impl.cpp#L3710-L3711&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;min(lastCommitted, stableTimestamp)&lt;/a&gt; if eMRC = false) which shouldn&apos;t include holes.&lt;/p&gt;</comment>
                            <comment id="2597976" author="siyuan.zhou@10gen.com" created="Wed, 11 Dec 2019 00:07:55 +0000"  >&lt;p&gt;To understand the problem more, I&apos;m wondering whether the previous transaction had majority write concern. If so, it should have waited for the holes before its commit time. It&apos;s true for a multi-node replset, but I&apos;m not sure if a primary of a single node replset waits for holes on majority write concern. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=ldeng&quot; class=&quot;user-hover&quot; rel=&quot;ldeng&quot;&gt;ldeng&lt;/a&gt; may know more about the behavior of majority write concern.&lt;/p&gt;

&lt;p&gt;I&apos;m also wondering if afterClusterTime is used in the following transaction. &quot;afterClusterTime&quot; should &lt;a href=&quot;https://github.com/mongodb/mongo/blob/169ab4da87a55a3c53d1686606f74e08748e8af2/src/mongo/db/repl/replication_coordinator_impl.cpp#L1496&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;wait for all concurrent writes to be visible&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="2597149" author="pavithra.vetriselvan" created="Tue, 10 Dec 2019 18:58:35 +0000"  >&lt;p&gt;Based on the linked failure, we can hit this scenario any time an operation reserves an oplog slot &lt;em&gt;before&lt;/em&gt; we update the transactions table. If we&apos;re starting a transaction with snapshot readConcern, its snapshot will not include that update. It seems like incorrect behavior for a new transaction to start without waiting for the previous transaction on the same session to update the transactions table.&lt;/p&gt;

&lt;p&gt;I think the most ideal option would be to wait for the transactions table update to be in the committed snapshot before starting a newer transaction with snapshot readConcern. We do something similar when calculating the stableOpTime and &lt;a href=&quot;https://github.com/mongodb/mongo/blob/d78c2f80751777ddcd4ebd1148c0c7a482b53e63/src/mongo/db/repl/replication_coordinator_impl.cpp#L3791-L3792&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;notifying waiters&lt;/a&gt;. I was looking into the work needed for the transactionParticipant to wait on the txn table write before &lt;a href=&quot;https://github.com/mongodb/mongo/blob/d78c2f80751777ddcd4ebd1148c0c7a482b53e63/src/mongo/db/transaction_participant.cpp#L1007-L1008&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;setting&lt;/a&gt; the readTimestamp, but the problem is that we don&apos;t know when the update to the transactions table will occur. Furthermore, this write does not generate an oplog entry, so I&apos;m not sure how easy it would be to get the timestamp. &lt;/p&gt;

&lt;p&gt;I originally considered making the write to the transactions table use writeConcern majority so that it would make it into the current committed snapshot (which is updated by the stableOpTime), but this would likely have a more significant impact on performance. &lt;/p&gt;

&lt;p&gt;Another option would be to keep track of the previous transaction&apos;s (per session) update to the transaction table. This could even be something as simple as a boolean field &quot;updatedTxnTable&quot; and explicitly wait for this to be true before starting a newer transaction.&lt;/p&gt;

&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; &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=siyuan.zhou&quot; class=&quot;user-hover&quot; rel=&quot;siyuan.zhou&quot;&gt;siyuan.zhou&lt;/a&gt; any thoughts here? Is this the direction we&apos;d like to take this ticket?&lt;/p&gt;</comment>
                            <comment id="2504739" author="jason.chan" created="Mon, 28 Oct 2019 14:00:18 +0000"  >&lt;p&gt;Yes, &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-42225&quot; title=&quot;timestamped_reads_wait_for_prepare_oplog_visibility.js should insert documents with write concern majority to guarantee visibility in transactions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-42225&quot;&gt;&lt;del&gt;SERVER-42225&lt;/del&gt;&lt;/a&gt; and &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-41769&quot; title=&quot;The committedSnapshot should not be greater than allCommitted when EMRC=false&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-41769&quot;&gt;&lt;del&gt;SERVER-41769&lt;/del&gt;&lt;/a&gt; addressed specific tests that this was happening and also an audit was performed on the existing tests at the time to make sure that any operations we expect to be in the snapshot are majority committed  before starting the new transaction. Since this test was newly added after the audit, it wasn&apos;t covered by the aforementioned tickets.&lt;/p&gt;</comment>
                            <comment id="2504605" author="judah.schvimer" created="Mon, 28 Oct 2019 13:15:55 +0000"  >&lt;p&gt;This sounds like another example of &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-42225&quot; title=&quot;timestamped_reads_wait_for_prepare_oplog_visibility.js should insert documents with write concern majority to guarantee visibility in transactions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-42225&quot;&gt;&lt;del&gt;SERVER-42225&lt;/del&gt;&lt;/a&gt;. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=jason.chan&quot; class=&quot;user-hover&quot; rel=&quot;jason.chan&quot;&gt;jason.chan&lt;/a&gt;, is that right?&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10420">
                    <name>Backports</name>
                                            <outwardlinks description="backported by">
                                                        </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="1081779">SERVER-45430</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="631366">SERVER-38028</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>12.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>5.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_12450" key="com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes">
                        <customfieldname>Backport Requested</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="16775"><![CDATA[v4.2]]></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>Mon, 28 Oct 2019 13:15:55 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        4 years, 3 weeks, 1 day 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_17050" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Downstream Team Attention</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="16941"><![CDATA[Not Needed]]></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>
                            4 years, 3 weeks, 1 day ago
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_16465" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Linked BF Score</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>7.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>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>jason.chan@mongodb.com</customfieldvalue>
            <customfieldvalue>judah.schvimer@mongodb.com</customfieldvalue>
            <customfieldvalue>lingzhi.deng@mongodb.com</customfieldvalue>
            <customfieldvalue>pavithra.vetriselvan@mongodb.com</customfieldvalue>
            <customfieldvalue>samy.lanka@mongodb.com</customfieldvalue>
            <customfieldvalue>siyuan.zhou@mongodb.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hvyzuv:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hr9jg7:</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="3304">Repl 2019-11-18</customfieldvalue>
    <customfieldvalue id="3437">Repl 2019-12-16</customfieldvalue>
    <customfieldvalue id="3438">Repl 2019-12-30</customfieldvalue>
    <customfieldvalue id="3439">Repl 2020-01-13</customfieldvalue>
    <customfieldvalue id="3440">Repl 2020-01-27</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|hvym47:</customfieldvalue>

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