Memory leak on the environments page

added bugperformance priority2 severity3 typebug labels

@ash2k, Please add a group or category label to identify issue ownership.

You can refer to the Features by Group handbook page for guidance.

If you are unsure about the correct group, please do not leave the issue without a group label, and refer to GitLab's shared responsibility functionality guidelines for more information on how to triage this kind of issue.

This message was generated automatically. You're welcome to improve it.

added devopsdeploy groupenvironments sectioncd labels

Hm, I'm trying to reproduce it but it's hasn't happen again so far...

Just wait a while. Left my laptop to have lunch with the page open. Came back and saw this. I was late to make the screenshot of the about:proceses page but it did show the same thing - lots of RAM consumed by the tab.

I could not reproduce it consistently either. Sometimes it crashed, but other times I could leave a page open for hours.

mentioned in issue gitlab-org/quality/triage-reports#15809 (closed)

@anna_vovchenko FYI

changed due date to April 18, 2024

changed milestone to %Backlog

added frontend workflowrefinement labels

mentioned in issue gitlab-org/quality/triage-reports#15882 (closed)

mentioned in issue gitlab-org/quality/triage-reports#15992 (closed)

added workflowplanning breakdown label and removed workflowrefinement label

added workflowrefinement label and removed workflowplanning breakdown label

mentioned in issue gitlab-org/ci-cd/deploy-stage/environments-group/general#66 (closed)

mentioned in issue gitlab-org/quality/triage-reports#16161 (closed)

I'm not really sure how to refine this one it would be nice to have more info on reproducing the issue but I think it'll need a bunch of investigation. I have seen on occasion the polling kind of blow up for some reason, and I wonder if this is causing that too.

As I'm going to tackle this in %16.10, I'll assign myself and give it a weight of 3 due to significant unknowns

added workflowready for development label and removed workflowrefinement label

set weight to 3

assigned to @afontaine

mentioned in issue gitlab-org/quality/triage-reports#16264 (closed)

added Deliverable label

changed milestone to %16.10

Setting health status to on track as the milestone has just begun.

Issue participants are welcome to override this by setting the health status to another value.

changed health status to on track

mentioned in issue gitlab-org/quality/triage-reports#16348 (closed)

mentioned in issue gitlab-org/quality/triage-reports#16453 (closed)

mentioned in issue gitlab-org/quality/triage-reports#16623 (closed)

This issue is scheduled for completion in this milestone but is not yet in development. Changing health status to 'needs attention'.

Issue participants are welcome to override this by setting the health status to another value.

changed health status to needs attention

changed milestone to %16.11

changed health status to on track

mentioned in issue gitlab-org/quality/triage-reports#16726 (closed)

mentioned in issue gitlab-org/quality/triage-reports#16806 (closed)

mentioned in issue gitlab-org/ci-cd/deploy-stage/environments-group/general#67 (closed)

mentioned in issue gitlab-org/cluster-integration/gitlab-agent#541 (closed)

mentioned in issue gitlab-org/quality/triage-reports#16912 (closed)

mentioned in issue gitlab-org/quality/triage-reports#16992 (closed)

This issue is scheduled for completion in this milestone but is not yet in development. Changing health status to 'needs attention'.

Issue participants are welcome to override this by setting the health status to another value.

changed health status to needs attention

mentioned in issue gitlab-org/quality/triage-reports#17186 (closed)

This issue is scheduled for completion in this milestone but is in an early development stage. Changing health status to 'at risk'.

Issue participants are welcome to override this by setting the health status to another value.

changed health status to at risk

mentioned in issue gitlab-org/quality/triage-reports#17265 (closed)

changed milestone to %17.0

changed milestone to %17.1

@afontaine While this bug is concerning I do not see much traction here, due to concurrent priorities I am moving this to 17.1 as Deliverable

Ah yes good call @nmezzopera! I realized I haven't written up the results of my investigation here, and only in our planning issue.

I have had a terrible time actually reproducing this issue, and have really only managed to reproduce this a couple times.

It looks like the main cause of the memory leak has to do with the apollo polling mechanism we use to ensure changes are reflected in the UI. My best bet is that we migrate to an apollo subscription so that the UI only receives updates when they happen, instead of continuously trying to fetch them.