<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 04:52:47 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-39680] Maintain the oldest active transaction timestamp only with the transaction table</title>
                <link>https://jira.mongodb.org/browse/SERVER-39680</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;The current plan for Prepare Support for Transactions uses an in-memory data structure to maintain the oldest active transaction timestamp. Instead, we can store the first oplog entry&apos;s timestamp of a transaction in the transaction table. Thus the transaction table has all necessary information to calculate the oldest active transaction timestamp. With &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-39679&quot; title=&quot;Add callback to replication when storage takes a checkpoint to learn of the maximum oplog truncation timestamp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-39679&quot;&gt;&lt;del&gt;SERVER-39679&lt;/del&gt;&lt;/a&gt;, this calculation may be done only when a checkpoint is taken or an initial sync starts, so its performance isn&apos;t a big concern. The updates on the transaction table are timestamped, so calculating the &lt;em&gt;oldest require timestamp&lt;/em&gt; is just a read at the checkpoint&apos;s timestamp.&lt;/p&gt;

&lt;p&gt;If table scan&apos;s performance isn&apos;t good enough, we can add an index on the &quot;firstTimestamp&quot; field. The index can be a partial index on &quot;firstTimestamp&quot; when a new &quot;active: true&quot; field exists, so that retryable writes and finished transactions don&apos;t affect the performance.&lt;/p&gt;</description>
                <environment></environment>
        <key id="700970">SERVER-39680</key>
            <summary>Maintain the oldest active transaction timestamp only with the transaction table</summary>
                <type id="3" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14718&amp;avatarType=issuetype">Task</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="jesse@mongodb.com">A. Jesse Jiryu Davis</assignee>
                                    <reporter username="siyuan.zhou@mongodb.com">Siyuan Zhou</reporter>
                        <labels>
                    </labels>
                <created>Tue, 19 Feb 2019 23:18:45 +0000</created>
                <updated>Sun, 29 Oct 2023 22:23:51 +0000</updated>
                            <resolved>Thu, 7 Mar 2019 17:31:08 +0000</resolved>
                                                    <fixVersion>4.1.9</fixVersion>
                                    <component>Replication</component>
                                        <votes>0</votes>
                                    <watches>7</watches>
                                                                                                                <comments>
                            <comment id="2219702" author="siyuan.zhou@10gen.com" created="Fri, 19 Apr 2019 21:24:43 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=david.golden&quot; class=&quot;user-hover&quot; rel=&quot;david.golden&quot;&gt;david.golden&lt;/a&gt;,&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-39813&quot; title=&quot;Add the oldest required timestamp into server status&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-39813&quot;&gt;&lt;del&gt;SERVER-39813&lt;/del&gt;&lt;/a&gt; is to track the work to expose&#160;the oldest active transaction timestamp. We still plan to the server status.&lt;/p&gt;</comment>
                            <comment id="2219581" author="david.golden" created="Fri, 19 Apr 2019 19:38:22 +0000"  >&lt;p&gt;For mongomirror and mongodump, could someone please summarize how these tools should determine the oldest active transaction timestamp?  The previous design discussions all assumed this would be available from &lt;tt&gt;serverStatus&lt;/tt&gt;.&lt;/p&gt;</comment>
                            <comment id="2174527" author="judah.schvimer" created="Thu, 7 Mar 2019 15:33:48 +0000"  >&lt;p&gt;I filed &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-40013&quot; title=&quot;upgrade downgrade support for config.transactions startTimestamp field&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-40013&quot;&gt;&lt;del&gt;SERVER-40013&lt;/del&gt;&lt;/a&gt; for the upgrade-downgrade work.&lt;/p&gt;</comment>
                            <comment id="2173102" author="judah.schvimer" created="Wed, 6 Mar 2019 19:20:44 +0000"  >&lt;p&gt;The upgrade-downgrade logic is also still todo, but can be done in a follow-up ticket or later on.&lt;/p&gt;</comment>
                            <comment id="2172545" author="xgen-internal-githook" created="Wed, 6 Mar 2019 14:29:46 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;A. Jesse Jiryu Davis&apos;, &apos;email&apos;: &apos;jesse@mongodb.com&apos;, &apos;username&apos;: &apos;ajdavis&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-39680&quot; title=&quot;Maintain the oldest active transaction timestamp only with the transaction table&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-39680&quot;&gt;&lt;del&gt;SERVER-39680&lt;/del&gt;&lt;/a&gt; Redundant test variable&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/8d09d4f70be8222f3e6818b19b5c678c18e9172e&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/8d09d4f70be8222f3e6818b19b5c678c18e9172e&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2172544" author="xgen-internal-githook" created="Wed, 6 Mar 2019 14:29:44 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;A. Jesse Jiryu Davis&apos;, &apos;email&apos;: &apos;jesse@mongodb.com&apos;, &apos;username&apos;: &apos;ajdavis&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-39680&quot; title=&quot;Maintain the oldest active transaction timestamp only with the transaction table&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-39680&quot;&gt;&lt;del&gt;SERVER-39680&lt;/del&gt;&lt;/a&gt; Save start timestamp in config.transactions&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/74eb8f3c5ad4e9010bed2fb8f50044df2db67948&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/74eb8f3c5ad4e9010bed2fb8f50044df2db67948&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2161464" author="judah.schvimer" created="Mon, 25 Feb 2019 14:59:35 +0000"  >&lt;p&gt;Thank you for the clarification. I may not have put that in the right implementation order, but I&apos;ll defer to you if you think this makes sense to do before finishing the parts required for &quot;prepare&quot;. I don&apos;t expect the upgrade-downgrade logic here to be very difficult since &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36498&quot; title=&quot;Remove &amp;#39;config.transactions&amp;#39; entries with &amp;#39;state&amp;#39; field on shutdown in fCV 4.0&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36498&quot;&gt;&lt;del&gt;SERVER-36498&lt;/del&gt;&lt;/a&gt; did most of the heavy lifting, but I do think that will be the hardest part of this ticket.&lt;/p&gt;</comment>
                            <comment id="2161384" author="jesse" created="Mon, 25 Feb 2019 14:14:49 +0000"  >&lt;p&gt;I think that doing this ticket is part of the plan at the bottom of&#160;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36494&quot; title=&quot;Prevent oplog truncation of oplog entries needed for startup recovery&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36494&quot;&gt;&lt;del&gt;SERVER-36494&lt;/del&gt;&lt;/a&gt;, right?&lt;/p&gt;

&lt;p&gt;&amp;gt; finding the OATT by doing a timestamped read on&#160;&lt;tt&gt;config.transactions&lt;/tt&gt;&#160;will be significantly easier for &#8220;Larger Transactions&#8221;, and sidestep the open questions of the original OATT design in Appendix II of the Prepare Design. As a result, we are going to pivot to that solution to save net work.&lt;/p&gt;

&lt;p&gt;I think this ticket has two parts: first, add and use a new field in the transactions table for tracking each transaction&apos;s oldest timestamp. Second, delete the in-memory data structure in ServerTransactionMetrics and use the transactions table exclusively. We have some freedom about the order in which we do the parts of this ticket and the parts of &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36494&quot; title=&quot;Prevent oplog truncation of oplog entries needed for startup recovery&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36494&quot;&gt;&lt;del&gt;SERVER-36494&lt;/del&gt;&lt;/a&gt;, but I think they&apos;re interdependent.&lt;/p&gt;</comment>
                            <comment id="2161340" author="judah.schvimer" created="Mon, 25 Feb 2019 13:43:54 +0000"  >&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;, is this required for &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36494&quot; title=&quot;Prevent oplog truncation of oplog entries needed for startup recovery&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36494&quot;&gt;&lt;del&gt;SERVER-36494&lt;/del&gt;&lt;/a&gt; or is this able to be follow-on work for compatibility with &quot;Larger Transactions&quot;?&lt;/p&gt;</comment>
                            <comment id="2160204" author="judah.schvimer" created="Fri, 22 Feb 2019 19:43:09 +0000"  >&lt;p&gt;This will need upgrade-downgrade logic similar to &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36498&quot; title=&quot;Remove &amp;#39;config.transactions&amp;#39; entries with &amp;#39;state&amp;#39; field on shutdown in fCV 4.0&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36498&quot;&gt;&lt;del&gt;SERVER-36498&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="2159361" author="jesse" created="Fri, 22 Feb 2019 03:01:56 +0000"  >&lt;p&gt;We can delete&#160;ServerTransactionsMetrics::getOldestActiveOpTime and related methods and data, I think, as part of this ticket.&lt;/p&gt;</comment>
                            <comment id="2159044" author="siyuan.zhou@10gen.com" created="Thu, 21 Feb 2019 21:09:09 +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; and I discussed the priority of this ticket. If we don&apos;t start this work, we would have to do these four tickets to maintain the timestamps in-memory for larger transactions.&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Maintain the oldest active transaction timestamp and the oldest required timestamp on primary.&lt;/li&gt;
	&lt;li&gt;Maintain the oldest active transaction timestamp and the oldest required timestamp on secondary&lt;/li&gt;
	&lt;li&gt;Reconstruct the in-memory data structures for active transactions on startup.&lt;/li&gt;
	&lt;li&gt;Reconstruct the in-memory data structures for active transactions on rollback (including rollback-via-refetch).&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;The first one might be simple, but updating the &quot;first timestamp&quot; on secondaries is more than just using a different timestamp, the work has to be done by SyncTail. Reconstructing in-memory data structures are also extra work beyond the Prepare project. This ticket also saves the write whenever the &lt;em&gt;oldest active transaction timestamp&lt;/em&gt; is updated, which matters since we want to ensure the performance parity with 4.0 for unprepared transactions.&lt;/p&gt;

&lt;p&gt;Thus, we want to prioritize this work and its dependency in storage interface, &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-39679&quot; title=&quot;Add callback to replication when storage takes a checkpoint to learn of the maximum oplog truncation timestamp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-39679&quot;&gt;&lt;del&gt;SERVER-39679&lt;/del&gt;&lt;/a&gt;. &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=daniel.gottlieb&quot; class=&quot;user-hover&quot; rel=&quot;daniel.gottlieb&quot;&gt;daniel.gottlieb&lt;/a&gt;, it&apos;d be great if storage team can prioritize &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-39679&quot; title=&quot;Add callback to replication when storage takes a checkpoint to learn of the maximum oplog truncation timestamp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-39679&quot;&gt;&lt;del&gt;SERVER-39679&lt;/del&gt;&lt;/a&gt;. Alternative, we can work on &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-39679&quot; title=&quot;Add callback to replication when storage takes a checkpoint to learn of the maximum oplog truncation timestamp&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-39679&quot;&gt;&lt;del&gt;SERVER-39679&lt;/del&gt;&lt;/a&gt; with your guidance and code review.&lt;/p&gt;

&lt;p&gt;I agree with &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=tess.avitabile&quot; class=&quot;user-hover&quot; rel=&quot;tess.avitabile&quot;&gt;tess.avitabile&lt;/a&gt; that we can let oplog to roll over when majority read concern is off in 4.2.0. If that turns out to be a problem, we could add the &quot;traversing oplog&quot; solution for it for later versions of 4.2.&lt;/p&gt;</comment>
                            <comment id="2158030" author="siyuan.zhou@10gen.com" created="Thu, 21 Feb 2019 04:52:08 +0000"  >&lt;p&gt;Larger Transaction will make the needed window of oplog larger than earlier versions. We could limit the size of transactions and write oplog entries of a transaction together to alleviate its impact. &lt;/p&gt;

&lt;p&gt;Another solution: if all oplog entries of a transaction are written together by reserving OpTimes together when majority reads is off, we can jump to the stable timestamp in the oplog and traverse back if it&apos;s a part of transaction to find its start, which is the oldest required timestamp. From the perspective of oplog, there&apos;s at most one active transaction at any time. To solve the large oplog hole problem, we can limit transaction size.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=daniel.gottlieb&quot; class=&quot;user-hover&quot; rel=&quot;daniel.gottlieb&quot;&gt;daniel.gottlieb&lt;/a&gt;, a follow-up question: what would happen when &quot;majority reads&quot; is turned on in terms of maintaining the stable timestamp?&lt;/p&gt;</comment>
                            <comment id="2156952" author="tess.avitabile" created="Wed, 20 Feb 2019 14:24:08 +0000"  >&lt;p&gt;We do not allow prepare when majority reads are disabled.&lt;/p&gt;

&lt;p&gt;If MongoDB has not historically kept sufficient oplog for rollback-via-refetch, then I do not believe we need to start doing so for the Larger Transactions project.&lt;/p&gt;</comment>
                            <comment id="2156944" author="daniel.gottlieb@10gen.com" created="Wed, 20 Feb 2019 14:20:22 +0000"  >&lt;blockquote&gt;
&lt;p&gt;Do you know if we always kept history back to the majority commit point in earlier versions?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;I don&apos;t believe we&apos;ve ever done that. Historically, MongoDB would only keep some amount of oplog measured in bytes. Only recently did we start keeping oplog back to the &quot;stable timestamp&quot; for replication recovery.&lt;/p&gt;

&lt;p&gt;Thinking pedantically about the problem though; if a &quot;majority reads off&quot; node is allowed to prepare and vote for transactions, I imagine there needs to be some guarantee about not throwing away the ledger of that transaction until its majority committed.&lt;/p&gt;</comment>
                            <comment id="2156903" author="tess.avitabile" created="Wed, 20 Feb 2019 13:59:35 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=daniel.gottlieb&quot; class=&quot;user-hover&quot; rel=&quot;daniel.gottlieb&quot;&gt;daniel.gottlieb&lt;/a&gt;, as I recall, this wasn&apos;t an explicit decision. Rather, since we don&apos;t use RTT when _keepDataHistory=false, we assumed we only need oplog for crash recovery. Do you know if we always kept history back to the majority commit point in earlier versions?&lt;/p&gt;</comment>
                            <comment id="2156570" author="daniel.gottlieb@10gen.com" created="Wed, 20 Feb 2019 01:31:51 +0000"  >&lt;p&gt;Re Siyuan&apos;s concern with majority reads off:&lt;/p&gt;

&lt;p&gt;&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; I &lt;a href=&quot;https://github.com/mongodb/mongo/blob/8d18f3593747f5ef5ca6f40cf37014de117e1c9d/src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp#L1884-L1887&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;can say how the code in master behaves (I think)&lt;/a&gt;, but I don&apos;t remember how much we explicitly decided on and how much I slipped in to avoid answering hard questions. If we did explicitly decide on this, this is your opportunity to opt for something more robust! I think the API for passing in the &quot;maximum truncation timestamp&quot; for a given fake &quot;stable&quot; timestamp was not expressive enough. Moving to a callback strategy removes that barrier.&lt;/p&gt;

&lt;p&gt;I believe with majority reads off, we only pin enough oplog to do replication recovery after a restart. If rollback via refetch discovers it needs some oplog entry that&apos;s been lopped off, the mongod will simply need to resync. If we thought that was good enough a couple months ago, perhaps it&apos;s still good enough now?&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                        <issuelink>
            <issuekey id="703843">SERVER-39792</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="712375">SERVER-40013</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="712526">SERVER-40018</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="704360">SERVER-39828</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="704367">SERVER-39829</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="711030">SERVER-39989</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="584990">SERVER-36494</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="700955">SERVER-39679</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="703894">SERVER-39813</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>17.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, 20 Feb 2019 01:31:51 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        4 years, 42 weeks, 5 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-1035</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, 42 weeks, 5 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>jesse@mongodb.com</customfieldvalue>
            <customfieldvalue>daniel.gottlieb@mongodb.com</customfieldvalue>
            <customfieldvalue>david.golden@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>judah.schvimer@mongodb.com</customfieldvalue>
            <customfieldvalue>siyuan.zhou@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|huo3sv:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hudutb:</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="2822">Repl 2019-03-11</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|hunq27:</customfieldvalue>

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