<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 04:48:08 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-38165] Test that prepared transactions work with an in-memory secondary</title>
                <link>https://jira.mongodb.org/browse/SERVER-38165</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37943&quot; title=&quot;Enable replica set transactions for the inMemory WT storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37943&quot;&gt;&lt;del&gt;SERVER-37943&lt;/del&gt;&lt;/a&gt; makes transactions work with the in-memory storage engine. In 4.0 an in-memory secondary can apply transactions, an in-memory primary just won&apos;t accept them. Even if we do not make transactions work on in-memory primaries, they must work for in-memory secondaries.&lt;/p&gt;</description>
                <environment></environment>
        <key id="634791">SERVER-38165</key>
            <summary>Test that prepared transactions work with an in-memory secondary</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="dianna.hohensee@mongodb.com">Dianna Hohensee</assignee>
                                    <reporter username="judah.schvimer@mongodb.com">Judah Schvimer</reporter>
                        <labels>
                            <label>prepare_basic</label>
                            <label>txn_storage</label>
                    </labels>
                <created>Thu, 15 Nov 2018 22:20:48 +0000</created>
                <updated>Sun, 29 Oct 2023 22:26:31 +0000</updated>
                            <resolved>Mon, 22 Apr 2019 18:02:54 +0000</resolved>
                                                    <fixVersion>4.1.11</fixVersion>
                                    <component>Replication</component>
                    <component>Testing Infrastructure</component>
                                        <votes>0</votes>
                                    <watches>6</watches>
                                                                                                                <comments>
                            <comment id="2221000" author="xgen-internal-githook" created="Mon, 22 Apr 2019 19:30:22 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;dianna.hohensee@10gen.com&apos;, &apos;name&apos;: &apos;Dianna&apos;, &apos;username&apos;: &apos;DiannaHohensee&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-38165&quot; title=&quot;Test that prepared transactions work with an in-memory secondary&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-38165&quot;&gt;&lt;del&gt;SERVER-38165&lt;/del&gt;&lt;/a&gt; add the &apos;requires_persistence&apos; tag to recover_prepared_transactions_startup_secondary_application.js so it does not run on the inMemory storage engine&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/8fea1553c0ddc6bf632d6d9e951a510892d6f1c5&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/8fea1553c0ddc6bf632d6d9e951a510892d6f1c5&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2220853" author="dianna.hohensee" created="Mon, 22 Apr 2019 18:14:51 +0000"  >&lt;p&gt;Cool. I just closed &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37943&quot; title=&quot;Enable replica set transactions for the inMemory WT storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37943&quot;&gt;&lt;del&gt;SERVER-37943&lt;/del&gt;&lt;/a&gt; as a dupe.&lt;/p&gt;</comment>
                            <comment id="2220842" author="judah.schvimer" created="Mon, 22 Apr 2019 18:10:57 +0000"  >&lt;p&gt;Can we close &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37943&quot; title=&quot;Enable replica set transactions for the inMemory WT storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37943&quot;&gt;&lt;del&gt;SERVER-37943&lt;/del&gt;&lt;/a&gt; as a duplicate?&lt;/p&gt;

&lt;p&gt;There are none that I know of. The above commit enables all testing, including sharded clusters. &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-40462&quot; title=&quot; Disallow transactions on shard servers with writeConcernMajorityJournalDefault = false&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-40462&quot;&gt;&lt;del&gt;SERVER-40462&lt;/del&gt;&lt;/a&gt; will need documentation changes around the behavior involving &lt;tt&gt;writeConcernMajorityJournalDefault&lt;/tt&gt;.&lt;/p&gt;</comment>
                            <comment id="2220832" author="dianna.hohensee" created="Mon, 22 Apr 2019 18:06:40 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=judah.schvimer&quot; class=&quot;user-hover&quot; rel=&quot;judah.schvimer&quot;&gt;judah.schvimer&lt;/a&gt;, I marked this as needing documentation, saying that transactions work on inMemory. I don&apos;t believe there are any qualifications on that, but wanted to check.&lt;/p&gt;</comment>
                            <comment id="2220784" author="xgen-internal-githook" created="Mon, 22 Apr 2019 17:39:16 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;email&apos;: &apos;dianna.hohensee@10gen.com&apos;, &apos;name&apos;: &apos;Dianna&apos;, &apos;username&apos;: &apos;DiannaHohensee&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-38165&quot; title=&quot;Test that prepared transactions work with an in-memory secondary&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-38165&quot;&gt;&lt;del&gt;SERVER-38165&lt;/del&gt;&lt;/a&gt; Enable transactions testing with the inMemory storage engine&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/96bf04156c9a78446f6b5dea988888427e032a2f&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/96bf04156c9a78446f6b5dea988888427e032a2f&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2197760" author="alyson.cabral" created="Mon, 1 Apr 2019 15:06:45 +0000"  >&lt;p&gt;Is it possible to ban transactions that come through the mongos for in-memory nodes? If so, that&apos;s my ideal. &lt;/p&gt;</comment>
                            <comment id="2193430" author="judah.schvimer" created="Wed, 27 Mar 2019 17:14:43 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=alyson.cabral&quot; class=&quot;user-hover&quot; rel=&quot;alyson.cabral&quot;&gt;alyson.cabral&lt;/a&gt;, I think the first question here is, how much do we have to support transactions on in-memory nodes? For both transactions that go through prepare and transactions that do not go through prepare, do we have to support them on in-memory primaries? Do we have to support them for in-memory secondaries that have a non-in-memory primary or are the in-memory secondaries allowed to fassert on seeing an oplog entry relevant to prepare or relevant to transactions in general?&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;If we are allowed to ban them on primaries, we should add the ban back in.&lt;/li&gt;
	&lt;li&gt;If we are only allowed to crash in-memory secondaries that see prepare, then we need to make that graceful and make &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; work for in-memory secondaries with Larger Transactions.&lt;/li&gt;
	&lt;li&gt;If we are allowed to crash in-memory secondaries that see any transaction oplog entry, then we only need to make that graceful.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="2193413" author="judah.schvimer" created="Wed, 27 Mar 2019 17:05:43 +0000"  >&lt;p&gt;This ticket will include (or should file other tickets for) any work to make sure in-memory nodes are both 1) able to truncate their oplog and 2) do not truncate their oplog prematurely for both Larger Transactions and Prepare post &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;.&lt;/p&gt;</comment>
                            <comment id="2175708" author="judah.schvimer" created="Fri, 8 Mar 2019 14:45:19 +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; and I discovered last night that we think &lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=dianna.hohensee&quot; class=&quot;user-hover&quot; rel=&quot;dianna.hohensee&quot;&gt;dianna.hohensee&lt;/a&gt; removed the code to ban transactions on in-memory nodes in &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-36072&quot; title=&quot;Remove enableInMemoryTransactions serverParameter when transactions are supported on inMemory&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-36072&quot;&gt;&lt;del&gt;SERVER-36072&lt;/del&gt;&lt;/a&gt;. &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37943&quot; title=&quot;Enable replica set transactions for the inMemory WT storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37943&quot;&gt;&lt;del&gt;SERVER-37943&lt;/del&gt;&lt;/a&gt; was just about re-enabling tests. It seems we may need to reintroduce the ban on transactions on in-memory nodes as part of this ticket if we choose to continue prohibiting them.&lt;/p&gt;</comment>
                            <comment id="2175687" author="tess.avitabile" created="Fri, 8 Mar 2019 14:34:03 +0000"  >&lt;p&gt;I don&apos;t believe we need to handle the case where in-memory secondaries with prepared transactions become primary. We would document that transactions are only supported on in-memory nodes with priority:0 or votes:0. Applications using transactions would not be built against replica sets with an in-memory node that could become primary, since transactions would stop succeeding when that node became primary. There is no issue with upgrading applications using transactions against replica sets to sharded clusters because applications using transactions cannot be built against replica sets with an in-memory node that could become primary.&lt;/p&gt;

&lt;p&gt;However, if there is any work involved in supporting rollback for Prepare or Larger Transactions on in-memory secondaries, then I am in favor of stopping support for this use case.&lt;/p&gt;</comment>
                            <comment id="2175281" author="judah.schvimer" created="Thu, 7 Mar 2019 23:17:55 +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;, we do not currently support transactions on in-memory nodes (&lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37943&quot; title=&quot;Enable replica set transactions for the inMemory WT storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37943&quot;&gt;&lt;del&gt;SERVER-37943&lt;/del&gt;&lt;/a&gt;), but we also do not do anything to prevent them from replicating to in-memory secondaries. In-memory nodes don&apos;t have any extra problems with resources, just we&apos;d run into problems if they could prepare transactions as a secondary but not commit or abort them as a primary, which is the direction we&apos;re heading in.&lt;/p&gt;</comment>
                            <comment id="2175273" author="siyuan.zhou@10gen.com" created="Thu, 7 Mar 2019 23:11:59 +0000"  >&lt;p&gt;I see Judah&apos;s point why the storage change to support &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; excludes the in-memory storage engine, but it&apos;s unclear to me how different that is from the current way in storage to truncate oplog on in-memory nodes. If I understand correctly, the concern about large transaction is that we used to allow transactions on in-memory nodes, but due to the new forma of large transactions, we&apos;d have to change the way of truncating oplog on in-memory nodes. That&apos;s a good point. Is it possible to call the callback to replication used by &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; without checkpointing?&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;If an in-memory secondary prepares a transaction and steps up as primary, but it cannot commit the transaction, does it just leave the transaction prepared indefinitely pinning resources?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;I agree that prepared and large transactions require more space to store the oplog, but I don&apos;t see why it&apos;s fundamentally different from the existing resource assumption of in-memory storage - the memory should be large enough for everything that used to be on disk.&lt;/p&gt;</comment>
                            <comment id="2175227" author="judah.schvimer" created="Thu, 7 Mar 2019 22:41:37 +0000"  >&lt;blockquote&gt;
&lt;p&gt;Since &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; is also used to ensure we keep enough oplog for larger transactions, does this mean that larger transactions will not work on in-memory secondaries?&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;I think that without more work, with larger transactions there is a chance that rollback would fail due to not having the oplog entries needed to recover. CC &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;/p&gt;</comment>
                            <comment id="2174748" author="tess.avitabile" created="Thu, 7 Mar 2019 18:05:22 +0000"  >&lt;p&gt;I believe this is for priority:0 in-memory secondaries, so we don&apos;t need to worry about the node becoming primary.&lt;/p&gt;

&lt;p&gt;Since&#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; is also used to ensure we keep enough oplog for larger transactions, does this mean that larger transactions will not work on in-memory secondaries?&lt;/p&gt;

&lt;p&gt;I am in favor of cutting work to support transactions on in-memory secondaries.&lt;/p&gt;</comment>
                            <comment id="2174684" author="judah.schvimer" created="Thu, 7 Mar 2019 17:11:41 +0000"  >&lt;p&gt;I&apos;m not actually sure that this ticket makes sense. If an in-memory secondary prepares a transaction and steps up as primary, but it cannot commit the transaction, does it just leave the transaction prepared indefinitely pinning resources? Additionally, having enough oplog for rollback was going to be a byproduct 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 that would no longer be the case for an in-memory storage engine since it doesn&apos;t take checkpoints. It would have to do something different to truncate the oplog but not truncate oplog entries required for RTT.&lt;/p&gt;

&lt;p&gt;I doubt &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37943&quot; title=&quot;Enable replica set transactions for the inMemory WT storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37943&quot;&gt;&lt;del&gt;SERVER-37943&lt;/del&gt;&lt;/a&gt; will land since it&apos;s not marked &quot;4.1 Required&quot;, but then I&apos;m not sure now to prevent an in-memory secondary from getting into a bad state. We could make &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-37943&quot; title=&quot;Enable replica set transactions for the inMemory WT storage engine&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-37943&quot;&gt;&lt;del&gt;SERVER-37943&lt;/del&gt;&lt;/a&gt; required, and add work to keep enough oplog for rollback with the in-memory storage engine (potentially with some periodic background job to query the &quot;oldest active transaction timestamp at the time of the stable timestamp&quot;). Alternatively we could just document that this is not allowed and &lt;tt&gt;fassert&lt;/tt&gt; in-memory secondaries that receive &lt;tt&gt;prepareTransaction&lt;/tt&gt; commands.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/secure/ViewProfile.jspa?name=alyson.cabral&quot; class=&quot;user-hover&quot; rel=&quot;alyson.cabral&quot;&gt;alyson.cabral&lt;/a&gt; and &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;, what do you think?&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10320">
                    <name>Documented</name>
                                                                <inwardlinks description="is documented by">
                                        <issuelink>
            <issuekey id="747309">DOCS-12657</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="629750">SERVER-37943</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10520">
                    <name>Problem/Incident</name>
                                            <outwardlinks description="causes">
                                                        </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="800714">SERVER-41699</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="729026">SERVER-40462</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="584990">SERVER-36494</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="629750">SERVER-37943</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>15.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2.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>Thu, 7 Mar 2019 18:05:22 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        4 years, 42 weeks, 2 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-1032</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, 2 days ago
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_16465" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Linked BF Score</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>alyson.cabral@mongodb.com</customfieldvalue>
            <customfieldvalue>dianna.hohensee@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|hud1jj:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hr7hgf:</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_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="2823">Repl 2019-03-25</customfieldvalue>
    <customfieldvalue id="2830">Storage NYC 2019-04-22</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|hucnsv:</customfieldvalue>

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