Container / Registry Split + Routing Refactor causes Global App Integration Test Issues

[rwjblue]

Changes to application boot on canary seem to have broken the ability to call app.reset() in a teardown callback to prepare for the next test. This likely affects globals style apps more than ember-cli applications, due to the fact that a new Ember.Application instance is created for each integration test.

The issue is that when routing is started (which happens on the first visit after calling app.reset()) we attempt to register view:toplevel and view:default (see here). However, due to the registry and container split, the registry is persistent across app.reset() calls, making the second call to container._registry.register('view:toplevel', EmberView.extend()) to fail with the following error:

Cannot re-register: `view:toplevel`, as it has already been resolved.

Demos:

Fails with canary builds JSBin
Works with beta builds JSBin

---

@dgeb / @wycats / @tomdale - This is directly related to y'all's work in this area, I'd definitely appreciate your feedback and suggested path forward here.

[dgeb]

I think the problem here is that we should be resetting the app's container and registry in reset until there is an app-instance-specific registry (see #10308). Once the app-instance-specific registry is introduced, it should receive these registrations instead of the app-specific registry. reset should then destroy the whole instance, including its registry and container.

So we could either fix this with a quick patch to canary or wait to merge the boot-reform branch.

[tomdale]

@dgeb After discussing this with @rwjblue, let's get #10308 merged in now that we have your fallback registry improvements in place.

[rwjblue]

Now that #10308 is merged into the boot-reform branch, I believe that we are pending #10271 to resolve this issue.

@tomdale - Is that correct?

[dgeb]

@rwjblue yes, in that branch the instance is destroyed on reset, which will clear the instance-specific registry and container as well.

[tomdale]

@rwjblue Can you verify this is fixed now that #10271 is merged?

[rwjblue]

The previously failing JSBin now passes properly. Thanks y'all for the hard work here!

[mutewinter]

@rwjblue I'm experiencing this issue with Ember 1.11 Beta 5.

Cannot re-register: `store:main`, as it has already been resolved.

I found this issue and I looking into how reset was functioning. I replace this code:

diff --git a/vendor/ember/development/ember.js b/vendor/ember/development/ember.js
index d4778f6..9b21660 100644
--- a/vendor/ember/development/ember.js
+++ b/vendor/ember/development/ember.js
@@ -3949,7 +3949,7 @@ enifed('ember-application/system/application', ['exports', 'dag-map', 'container
       return ApplicationInstance['default'].create({
         customEvents: property_get.get(this, 'customEvents'),
         rootElement: property_get.get(this, 'rootElement'),
-        applicationRegistry: this.registry
+        applicationRegistry: this.buildRegistry()
       });
     },

And it fixed my problem. Before the fix above, it seemed that the Registry stayed the same, even after an App.reset().

[btecu]

I can confirm I'm running into this issue where app.reset() doesn't take care of the registry with 1.11.0-beta.4 and 1.11.0-beta.5 (I haven't tested others).

[BlakeWilliams]

I've also hit this on both 1.11.0-beta.4 and 1.11.0-beta.5.

[tomdale]

I'll try to look into this today.

[kagemusha]

we're having this issue too. @mutewinter's fix works in our case. anyone still looking at this?

[martinstannard]

I'm seeing this on 1.11.1 too on an ember-rails app too.

[visoft]

I'm seeing this same problem too when testing using 1.11, @mutewinter's fix worked for me as well. I've been banging my head on this problem for days, glad I tried the fix.

[flowjzh]

Seeing this on 1.11.1 too and @mutewinter's fix works. This seems to be annoying and a main barrier for us to transfer to use 1.11.1 against 1.10, since almost all integration tests are broken.

[simonexmachina]

This does appear to be a current issue, can we get this resolved please! @tomdale?

[kagemusha]

@rwjblue would this get more love if put in a current milestone (instead of the already past 1.11.0 one)?

[matryo]

A good portion of our functional tests are broken because of this (under 1.11.3). @mutewinter's fix totally works. I imagine this is presently blocking a whole lot of people from moving to 1.11. When can we expect a patch release?

[szalishchuk]

Totally screwed up all integration tests for my project, once I've migrated to 1.11 and there's no way back, because I've refactored the code base to utilize new features (e.g. component helper). I'll wait patiently for the update.

[balinterdi]

@szalishchuk In the meantime, you can fork our fork: I took the last commit for the 1.11.3 version and applied mutewinter's fix on top of that. You will need to build/deploy that Ember version, for which end you can just use bower link (simpler) or do as I did (a bit more complex)

[szalishchuk]

@balinterdi Thank you very much! Why don't you submit your fix as a PR?

[balinterdi]

The fix is not mine but @mutewinter's (see above) and since I'm not intimate with the internals of the container/registry, I'm not sure if the fix is a real solution or just a hack. Above that, a failing unit test should be provided that highlights the bug (that the fix then squashes) and I would be at a loss regarding how to write it :)

[mutewinter]

The fix is not mine but @mutewinter's (see above) and since I'm not intimate with the internals of the container/registry, I'm not sure if the fix is a real solution or just a hack. Above that, a failing unit test should be provided that highlights the bug (that the fix then squashes) and I would be at a loss regarding how to write it :)

Yeah I'm not sure if it's a hack or a real fix either. I was asked in #10597 to write a test, but I'm not sure what a test for this looks like.

[kagemusha]

If you don't want to futz with ember itself, you can try to apply the @mutewinter fix in your test code. Wherever you do a refresh rebuild the registry first:

app.registry = app.buildRegistry()
app.reset()

We made this a method called safeRefresh and use it instead of raw reset calls. It generally works, but has failed in a couple tests which we've commented out for now.

[ehntoo]

Throwing my hat into the ring for hacks that don't require moving from upstream: Use an initializer. Yeah. It's really, really, really horrible. :)

import Ember from 'ember';

var originalBuildInstance;

export function initialize(/*container, application*/) {
  originalBuildInstance = originalBuildInstance || Ember.Application.prototype.buildInstance;
  Ember.Application.prototype.buildInstance = function() {
    this.registry = this.buildRegistry();
    return originalBuildInstance.apply(this);
  };
}

export default {
  name: 'horrible-reset-hack',
  initialize: initialize
};

[alvinvogelzang]

@kagemusha what kind of tests are failing in your application with this fix? For me only the first test is working and after that it looks like the setup isn't creating a new ember app.

[kagemusha]

@alvinvogelzang get the same error as without it: Cannot re-register: ..., as it has already been resolved.

[hscharitzer]

We are experiencing the same issue on version 1.13 and it's causing all of our acceptance tests to fail.

We are using @ehntoo hack to temporarily run our tests, but feedback would be appreciated.

[matthiasleitner]

Seeing the same issue with 1.13.

[rwjblue]

Things seem to work properly when using both Ember and Ember Data at 2.0.0 JSBin.

Using Ember and Ember Data 1.13.9 throws the error that @mutewinter mentioned above (JSBin):

Cannot re-register: `service:store`, as it has already been resolved.

[rwjblue]

emberjs/data#3690 should fix the issue up in Ember Data, but I am unsure if they will want to release a 1.13.12 for just that change. A potential interim work around would be adding an initializer like the following:

App.initializer({
  name: 'clear-service-store',
  before: ['ember-data'],
  initialize(registry) {
    registry.unregister('service:store');
  }
});

Demo: http://emberjs.jsbin.com/dawebo/1/edit?html,js,output.

[rwjblue]

Closing this again, as I believe the work around and PR to Ember Data should solve the issue for most everyone.

Sorry for the long delay on this, please let me know if there are additional errors/issues and I will reopen (if related).