This issue relates to #592 and will be addressed together with it.

After some investigation, I was able to pin down this issue and split it into a two-part fix. The root cause of the issue is due to the way the submission trend is calculated. It is done by listing the entries that match the specific conditions (date and some parameters) and then aggregating and counting them. The problem with this approach is that it uses a lot of resources for aggregation, as it will quadruple the memory used for resource loading due to the mapping. Due to that, the maximum amount of memory that the application could use would go through the roof, and the application would restart with an Out of Memory exception that is not that easy to capture in a cloud environment. To fix this, we came up with the following changes:

The first part is being addressed by the PR 618 by increasing the resource limit for the application. This should solve not only this issue but some other issues as well.

The second part is being addressed by the PR 619, where the aggregation code was changed and the heaviest part of the aggregation was moved to the query itself.