Container still left in memory after test run

[jbryson3]

I've just begun the journey to identify memory leaks in my ember application. I'm getting started with the steps outlined on ember-map. Basically, run tests, take heap snapshot, and look for the existence of Container.

I generally have two different types of Container left after a test, my application container, and a container coming from mirage-esm.js. Even if I am not using mirage in the test, or have skipped the test completely, the mIrage container still shows up.

Am I leaking memory in my test run due to multiple mirage containers?

To reproduce, install ember-cli-mirage to a new ember app.

1. npm i -g ember-cli
2. ember init
3. ember install ember-cli-mirage
4. ember test --server
5. After test run, open dev tools
6. Go to memory tab
7. Take heap snapshot
8. Search for 'Container'

[adc-mhaugen]

I too am seeing this issue. What I've found is that by adding ember-cli-mirage to my project, but not using it, I see a single mirage Container leak:

Then, if I call the setupMirage function within my acceptance test, I get a second mirage Container leak:

Finally, if I modify my application route to request the model from the store and create the model in my acceptance test, I see an ember Container leak:

Including the model, application route and router:

[sebastianhelbig]

Anyone found a solution for this? I am experiencing the same problem 😞

[cah-brian-gantzler]

I believe Mirage is getting started automatically in your tests here https://github.com/miragejs/ember-cli-mirage/blob/master/packages/ember-cli-mirage/app/initializers/ember-cli-mirage.js#L32 because of this https://github.com/miragejs/ember-cli-mirage/blob/master/packages/ember-cli-mirage/app/initializers/ember-cli-mirage.js#L55

I note that when it starts the server for running in development here https://github.com/miragejs/ember-cli-mirage/blob/master/packages/ember-cli-mirage/addon/instance-initializers/ember-cli-mirage-autostart.js#L22 it also registers the server to be destroyed. Thats because there is one start and one end. In tests there are many.

SetupMirage starts the server https://github.com/miragejs/ember-cli-mirage/blob/master/packages/ember-cli-mirage/addon-test-support/setup-mirage.js#L23 and destroys it https://github.com/miragejs/ember-cli-mirage/blob/master/packages/ember-cli-mirage/addon-test-support/setup-mirage.js#L29 for each test.

I wonder why it starts the server and then starts it again during SetupMirage. Setting up Mirage also sets up pretender, if you call SetupMirage twice you usually get an error stating you cant create a second pretender.

Just observations. I dont know why you have a container left over.

This addon is really just a convenience for adding MirageJS (since it was extracted). For your test, we could NOT use ember-cli-mirage and use MirageJS hard, then we could see if the container left over is MirageJS responsibility or ember-cli-mirage responsibility

[cah-brian-gantzler]

What is the code that is doing the asserts for this? Mirage is NOT torn down til after the test completes, so I would expect you would see the containers still there