Ember tests running really slowly for anyone else after upgrade to 3.28.1?

1

I am upgrading an Ember addon we have written to 3.28.1 and after a fair bit of debugging I think I have found what is slowing down the unit tests.

When running the tests I find that they run fine once in the terminal, but when I make a code change it takes over a minute for it to reload (the tests running in the browser are also slowed down by this delay as well).

After commenting out lots of code I have found that it is an observer that seems to be causing this slow down. I appreciate observers are not deprecated now, but don’t fancy trying to refactor this bit of code as part of this work and I don’t really want to remove the unit tests that cover functionality that hits the observer. I have checked and it seems the observer is only hit twice in the tests so it’s not like it is triggering lots and causing issues.

However, when I run the unit tests in the production environment the tests run fine (except that it takes 10 to 15 seconds to rebuild after a code change then the tests run again).

I assume there is some deprecation checking that is going on with observers in non-production environment that is causing this issue?

2

Strange. So I have converted the observers to use did-update modifiers instead and still having issues with tests taking ages to reload. Must be something in my code…?

3

So I commented out the code from within the actions that get called by did-update modifiers and have the slow reloading issue (?) but if I remove the did-update modifiers from the template everything works fine again (except failing unit tests). So I seem to be having issues just having (empty) functions that are getting triggered by observers or did-update modifiers regardless of their content.

I’ll see if I can replicate in a different project…

I couldn’t figure out how to replicate with a smaller example in a different project so we will have to run in production environment and try and go back to test environment in the future.

4

what’s your optional-features.json file look like?

5

Just looks like:

{
    "jquery-integration": true
}

but in tests/dummy/config/optional-features.json we have:

{
  "application-template-wrapper": false,
  "jquery-integration": true,
  "template-only-glimmer-components": true
}

I just found:

I don’t know whether my issue is similar but happens quickly instead of the 20 or 30 minutes mentioned in that case?

6

so, if you’re using observers in octane, I know you need(1) this for your optional-features

{
  "application-template-wrapper": false,
  "default-async-observers": true,
  "jquery-integration": false,
  "template-only-glimmer-components": true
}

the default without default-async-observers is false (for back compat) – so if you add that option to your app/addon optional-features, do things run faster?

  1. need is a bit strong – the option exists because there is a perf hit to using sync-observers
7

Thanks, I have added those, and I think they will help.

I am still having problems though, and I think I know why. Things seem to grind to a halt when I go to localhost:7357 in a Firefox browser (don’t know why I didn’t make this connection before). Going there in a chrome browser still slows things down a little, but not as much as connecting with Firefox. If I just run the tests in the terminal by itself, things seem to be fine.

8

anything sus logged in the browser consoles?

9

After making a change in a file and waiting 60 seconds (I think - seems like a usual HTTP request timeout amount of time) in the browser (console) it eventually reports:

The connection to ws://localhost:7357/socket.io/?EIO=4&transport=websocket&sid=2fSqEu_hp5miLLdjAAAE was interrupted while the page was loading.

10

socket.io? what’s that endpoint? that’s not an ember-default thing afaik

11

I think socket.io is a testem dependency?

I have finally got things running quickly and it’s to do with deprecation messages (I thought so as it was running ok in production environment). I need to work through them but for the time being I have used

to ignore deprecation messages (I just print out the deprecation IDs once myself, but I don’t let it spam the console) and everything seems to be working nice and smoothly again.

12

have you seen GitHub - mixonic/ember-cli-deprecation-workflow ?

it’s a little less manual than using registerDeprecationHandler

13

I had seen that and that was next on my list of things to try, I should have done that before trying to get tests working. Although I imagine I will still have a lot of deprecation warnings after using that library as we are still using some older libraries.

Thanks for the help.