Vague errors in production only

[tarponjargon]

I deployed a demo app I’ve been working on to “production” at https://shop.thewhiteroom.com/

Everything is fine in my dev environment, but there are vague mystery errors around user login/checkout only in production.

(click “my account” then click into the e-mail address field and see all the red ink in the console)

I have no idea how to track them down. The links in the stacktrace point to the minified source of ember, so are not revealing at all.

Uncaught TypeError: Cannot read property 'isDestroyed' of null
    at Ae (vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:2390)
    at o.setUnknownProperty (vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:2949)
    at Ae (vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:2395)
    at t.(/anonymous function) [as __UPDATE__ember1525799957157465729349142__] (https://shop.thewhiteroom.com/assets/vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:1924:177)
    at o.c.CoreView.extend.(/anonymous function) [as __PROPERTY_DID_CHANGE__ember1525799957157314235040647__] (https://shop.thewhiteroom.com/assets/vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:1943:14)
    at F (vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:2301)
    at Ae (vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:2395)
    at t.(/anonymous function) [as __UPDATE__ember1525799957157465729349142__] (https://shop.thewhiteroom.com/assets/vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:1920:59)
    at o.c.CoreView.extend.(/anonymous function) [as __PROPERTY_DID_CHANGE__ember1525799957157314235040647__] (https://shop.thewhiteroom.com/assets/vendor-e1ae7c2a1320a5d2a22f97927fab4b2c.js:1943:14)

I can usually sleuth out vague ember errors, but it’s the fact that it only happens in production which is baffling me. Can anyone recommend an approach on how to debug this one? Or does the error ring a bell?

[rondale_sc]

One little trick to help with things like this is to use the expand minification option in Chrome devtools:

Once you’ve done that you can set a breakpoint on the first line and follow the stack trace. You’ll likely see familiar code that you can investigate. Use the knowledge you gain there to reproduce the error on your local dev environment.

This seems like you are call isDestroyed on a null object. I also see setUnknownProperty in there which means you’re likely dealing with a proxy object.

Hope this helps get you started.

Goodluck!

[ef4]

I took a look at your deployed example, and it looks like something is trying to set through a chain of references where one of the intermediate objects is undefined. If I’m reading it right, the chain is named cart.cartObj.email.email. Maybe the extra .email is unintentional – that could be the cause of the bug.

I found this by breaking at the exception, then looking upward through the stack to see where the undefined object was coming from. It comes from here. If we break in that exact spot, we can look at the chain of references that are being traversed via this._propertyKey and this._parentReference.

If it turns out my guess is right, I would be curious why this doesn’t also cause exceptions in development mode. That could be an ember bug.

A couple other debugging tricks:

• you can run interactive ember-cli in production mode with ember s --environment=production, which may make poking and prodding easier.

• you can disable minification of production builds. It would look something like this in ember-cli-build.js:

  let app = new EmberApp(defaults, {
    minifyJS: {
      enabled: false
    }
  });
  

[tarponjargon]

Thanks to you both for taking a look - I appreciate it.

I took a look at your deployed example, and it looks like something is trying to set through a chain of references where one of the intermediate objects is undefined. If I’m reading it right, the chain is named cart.cartObj.email.email. Maybe the extra .email is unintentional – that could be the cause of the bug.

It’s intentional, email is a model, with a property email (among others). But I am very interested in knowing how you were able to trace the error back to cart.cartObj.email.email

I stuck a breakpoint on:

var t = this._parentReference.value();

And I can step into the error…but I’m so curious how you were able to find the actual object name. If you have a chance let me know.

you can run interactive ember-cli in production mode with ember s --environment=production, which may make poking and prodding easier.

This is a good trick! Very strangely, I can run the production build locally with this command, and the error does not happen! argh.

UPDATE: It does actually happen on development - I had a persistent session going on dev that was masking the issue.

you can disable minification of production builds. It would look something like this in ember-cli-build.js:

That was actually the first thing I tried. But, it doesn’t seem to work anymore. To see if it was just my app, I ran

ember new testproj
cd testproj

modified the ember-cli-build.js to this:

Then ran

ember s

And the code isn’t minimized (screenshot below). Cleared cache, etc. Do you know if support for that has been removed? Or maybe I’m just doing it wrong. I am on ember 3.1.0

[ef4]

@tarponjargon

And I can step into the error…but I’m so curious how you were able to find the actual object name. If you have a chance let me know.

The ember code we’re looking at is part of NestedPropertyReference.

A NestedPropertyReference is what you get when you say something like {{model.name}} – there is already some existing model reference , and we’re deriving a new child reference from it. The child reference stores _parentReference so it can look up the current value of model and it stores "name" in its _propertyKey so it knows which property to pull off the model.

In your case, the _parentReference is also another NestedPropertyReference, so it too has a _propertyKey and _parentReference, so we can keep looking upward at the names:

this._propertyKey
this._parentReference._propertyKey
this._parentReference._parentReference._propertyKey
this._parentReference._parentReference._parentReference._propertyKey

That’s how I figured out cart.cartObj.email.email. And your app bug is definitely that one of those intermediate values is undefined when you’re trying to set on it.

Here is a good summary of the References architecture. This stuff is all internals that users shouldn’t need to learn about unless they want to. Probably the real Ember issue here is that we should make this exception message more useful.

[tarponjargon]

Thanks so much for taking the time to explain! I learned alot!