setupOnerror is running twice in Octane-3.15

[ELepolt]

When manually asserting an error in a component, setupOnerror is running twice, the first time err.message is the expected error, and the second time I'm receiving Cannot read property 'firstNode' of null.

Steps to reproduce:

ember new my-app
cd my-app

ember g component my-component -gc

my-component.js

import Component from '@glimmer/component';
import { assert } from '@ember/debug';


export default class MyComponentComponent extends Component {
  constructor() {
    super(...arguments);
    assert('test');
  }
}

my-component-test.js

import { module, test } from 'qunit';
import { setupRenderingTest } from 'ember-qunit';
import { render, setupOnerror } from '@ember/test-helpers';
import { hbs } from 'ember-cli-htmlbars';

module('Integration | Component | my-component', function(hooks) {
  setupRenderingTest(hooks);

  test('it does not render', async function(assert) {
    setupOnerror(function(err) {
      assert.equal(err.message, 'Assertion Failed: test');
    });
    await render(hbs`<MyComponent />`);
  });
});

The output from the above test is slightly different than my production output:

I also tested this in the LTS version and it did not occur, it simply ran once with the expected err.message.

My apologies if this is user error.

[ELepolt]

Dug a little deeper this morning, the second issue is coming from @glimmer/runtime.js in the SimpleBlockTracker class it's calling this code:

    firstNode() {
        var first = this.first;
        return first.firstNode();
    }

And in this case, this.first is null. this.parent is the #ember-testing div. I'm not sure exactly what this means in regards to whom this bug report should actually belong to, so let me know if I'm no longer in the right place.

[MuseofMoose]

Seeing the exact same issue. Note that I also get this issue when using the old way of overwriting Ember.onerror, too. I initially thought this error was popping up due to not using the new approach (I'm migrating to Octane, presently) but that is clearly not the case.

[rwjblue]

Can you make a runnable demo repo, might make it easier to dig in.

Also, I suspect that this is not actually an issue in @ember/test-helpers itself but some sort of change in cleanup/destruction. It's just hard to confirm which project is at fault until we can step through a repro.

[ELepolt]

https://github.com/ELepolt/test-helpers-example

[rwjblue]

Looks like what is happening is that there is a second error that is thrown during tear down itself. I’ll need to dig in a bit more to see why it changed specifically, but given that it is introduced in 3.13 I believe that it is likely related to the auto tracking work.

Thank you for the reproduction!

[rwjblue]

@ELepolt - I was looking at this with @pzuraq and we see the same issue on Ember 3.12, but you mentioned that it didn't happen on the current LTS (which I interpretted to be 3.12.3). Can you confirm?

[ELepolt]

3.12.1 is working

https://github.com/ELepolt/test-helpers-example-lts/

[svsalvador]

Hi,

I have the same issue in the project I am working right now. Triaging the error I have found that activating the optional feature application-template-wrapper the issue disappears (you must remove the edition: octane in the package.json to be able to do that).

It can be reproduced in the same repo that @ELepolt has shared: https://github.com/ELepolt/test-helpers-example.

I hope it helps.

Regards.

[rwjblue]

FWIW, fixes for this are incoming. Main upstream fix (and explanation) in glimmerjs/glimmer-vm#1073, but we are working to get those glimmer-vm changes landed in Ember releases now. Likely to be fixed for 3.16 and 3.18+.