Addon tests frequently fail when running multi-process #799
Labels
bug
Something isn't working
Comments
bendemboski
added a commit
to bendemboski/ember-add-listener-helper
that referenced
this issue
May 5, 2021
|
FYI, also running into this with an addon. For me, deleting |
bendemboski
added a commit
to bendemboski/ember-add-listener-helper
that referenced
this issue
May 10, 2021
|
I think this may have been fixed by #881 |
|
hi, just wondering if this is fixed? @bendemboski |
|
Yes, it has! I've been running without the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If
JOBSis not set to1andthread-loaderis active, addon tests will frequently (but non-deterministically) fail complaining about missing imports forqunitand other dependencies that are only imported from the tests/dummy app.Symptoms
Sometimes the entire test run will fail because of an error importing
qunitfromtest-helper.js:Sometimes
test-helper.js' import will succeed, but individual test modules will fail to load withProximate cause
The proximate cause of this is that certain modules will end up trying to import
qunitas an external:Which modules this happen to is non-deterministic, although the above results get saved to the babel loader cache (
$TMPDIR/embroider/webpack-babel-loader), so barring clearing the cache or making changes to the source files, it will look deterministic, but it's really just a tainted cache.This, in turn, is happening because in a multi-process build environment, in some of the
thread-loaderworker processes, when this code runs on files in the tests/dummy app, the dummy app is not in the root package cache, so we think that the files are part of the addon itself rather than the addon's dummy app. Sincequnit(and potentially other libraries as well) are only installed in the dummy app, and not the addon, we fail to resolve them relative to the addon and mark them as external.Root cause
From conversations with @ef4, the root cause is that the code that runs in the worker processes when in a multi-process build environment relies on the package cache already having been imperatively seeded, but that seeding only happens in the main build process, not the
thread-loaderworker processes.Further data
After doing a whole bunch of
console.log()debugging, it appears that the non-determinism is related to the order that babel plugins are invoked in the worker process. Anytimetemplate-colocation-pluginis invoked on a file that lives in the tests/dummy app, it will add the dummy app to the root package cache if it's not already added. Anytimebabel-plugin-adjust-importsruns on such a file, it will not add the dummy app to the root package cache, so if the dummy app is already in the cache, the plugin will resolve things correctly, but if the dummy app is not in the cache, it will think the test file is part of the addon and resolve any imports of test-only packages as externals. Hence, what determines whether the adjust imports plugin will do the wrong thing or not is whether the colocation plugin has previously run on a test file in that worker process, and that's non-deterministic.I am somewhat stumped as to why
template-colocation-pluginis able to correctly add the dummy app to the cache when it callsPackageCache.ownerOfFile(), butbabel-plugin-adjust-importsis not. This is a sample stack trace oftemplate-colocation-pluginadding it:For some reason this call results in correctly adding the dummy app to the cache, while this call (invoked from here) does not.
Workaround
A workaround is to run with
JOBS=1to disablethread-loaderand run everything in one process, so the imperative seeding happens in the same process in which the loaders/plugins run. However, you will also likely need to delete$TMPDIR/embroider/webpack-babel-loader, which will have cached versions of transpiled files with incorrect import resolutions.The text was updated successfully, but these errors were encountered: