Remove "process already captured" errors.

[rwjblue]

This has been a very annoying source of CI failures. If it were technically more correct I'd say we should keep it around and attempt to fix the underlying issue, but I do not think it is. In most cases, we are either setting up on the same object (in which case no need to release any existing handlers) or we are providing a custom MockProcess object which really won't ever need capturing.

[ro0gr]

If I remember correctly, in case if ember-cli would capture the process twice, it would not properly dispose stuff from the first capture. This was a reason why I've introduced this exception(sorry for a constant problems with this!).

Is it some kind of sporadic failures of the ember-cli's own CI, or does it cause some issues for external projects?

[rwjblue]

Is it some kind of sporadic failures of the ember-cli's own CI

Ya, it is due to us using tests/helpers/ember.js to invoke the CLI from within the same process many times (some of our tests use execa + a new process but others use that helper).

[rwjblue]

Here is an example failure:

https://github.com/ember-cli/ember-cli/pull/9336/checks?check_run_id=1150804964#step:5:91

[ro0gr]

Seems like the failure occurrs only when the tests/helpers/ember.js is used? If such, can we maybe release( only when the test helper is used? This way, we'd be resilent to the test setup, and leave the userland code guard in place?

[ro0gr]

If that sounds reasonable, I can take a look at it this week.

[ro0gr]

If I remember correctly, in case if ember-cli would capture the process twice, it would not properly dispose stuff from the first capture.

I've just checked capture-exit, and seems like double capture should not really cause the issue.

Though, in my taste, it still might be a good idea to preserve the exception in order to avoid accidental double capture coming from the /lib, your change looks good to me.

[rwjblue]

I've just checked capture-exit, and seems like double capture should not really cause the issue.

Ya, capture-exit always captures whatever process is (and we do not pass the value that is passed in to us).

[rwjblue]

If that sounds reasonable, I can take a look at it this week.

Ya, I'm happy to try that before completely removing (though I think the part of the changes here that are "if the process is the same thing, carry on" are probably still fine) if you have the time to look into it.

FWIW, I also considered adding a .release() call in the global afterEach we have in tests/runner.js. This would at least prevent "knock on failures" (where every subsequent test fails once any test fails).

[ro0gr]

Thanks, I'd definitely give it a try!

"if the process is the same thing, carry on" are probably still fine

Yes, it's clever, and it makes sense in terms of the capture-exit.

However, due to the requirement for the will-interrupt-process to be invoked at the very begining of the process, from the ember-cli's /lib perspective, I believe it doesn't make sense to allow it being called twice within the same process. It just feels pointless to invoke it twice. Though I realize, it may be just a matter of my bias.

adding a .release() call in the global afterEach we have in tests/runner.js

Ya, that's an option. I think the drawback of this is that, tests/helpers/ember is a public API of ember-cli(I believe). So someone using this test helper may experience the same issue in their addon's test suite.

[ro0gr]

A side note.

I've just checked few more builds with this failure:

• MacOS - https://github.com/ember-cli/ember-cli/pull/9338/checks?check_run_id=1151483704#step:5:91
• Windows - https://github.com/ember-cli/ember-cli/pull/9300/checks?check_run_id=948998976#step:5:81

each time, the same test triggers the initial error:

ember new npm blueprint with old version

This is suspicious at least...

[rwjblue]

Ya, that's an option. I think the drawback of this is that, tests/helpers/ember is a public API of ember-cli(I believe). So someone using this test helper may experience the same issue in their addon's test suite.

Ya, totally agree with you here. I absolutely would prefer to get this squared away without sacrificing strictness.