Trying to unregister a portal "${name}" when PortalTarget tears down before next.

[deanmarano]

Hi! I'm upgrading from ember-stargate 0.2.0 to 0.4.3 (on Ember 3.24). It looks like this PR moved the registerPortal call into a next call.

This causes a bug when transitioning to my error route. When the PortalTarget first renders, it calls registerPortal. The transition to the error route happens before the next is called, and unregisterPortal is called before registerPortal gets to the next call, which throws the error from the title.

I'd be happy to work on a fix for this, but I'd like to do it in a way that makes sense. My first thought is to put the contents of unregisterPortal into a next loop as well.

[st-h]

Looks like this is the same issue I have been seeing in fastboot mode here: #413 - however I do not transition to a different route (I haven't seen that issue in non fastboot mode though...). Also it only appears when there is content rendered inside the portal.

Today I was finally debugging fastboot mode and I had very similar findings.

• the modify hook in the portal component is called
• the destructor is invoked, calling this.portalService.unregisterPortal(this._target). This causes the error.
• then the code in the next() block in the modify hook is executed, which tries to register the portal for the first time

I am a bit puzzled why the destructor is being called before the stargate setup is completed - except that the app seems to be torn down before ember-stargate is done initializing itself fully. If I go back in the stacktrace, I end up in ember-app.js where the _destroy() method is called inside the visit() method. I also noticed that in ember-stargate Portals are not rendered in FastBoot mode - makes sense if the portal isn't even registered before the app is torn down. I just have no idea why this is happening.

Probably the best way to fix this is by setting a destroyed flag in the destructor, so one can make the code in the next() method a noop and stop trying to destroy a portal that hasn't been registered yet? Otherwise wrapping the destructor content in next() as well might also work. Then the portal would likely be registered and very soon deregistered again. However, the question also comes up, why the next() block is needed in first place? Also that will not fix that fastboot is unable to render the portals - but just remove the error.

@simonihmig any thoughts about that?

[simonihmig]

I think the original bug report should get fixed by #644. Will look into the fastboot story next...