You’re very likely running into a side effect of the differences between
this.model explored in some detail in this GitHub issue. As described there, the
@model value in a route template is exactly the model as it was resolved by the
model (and potentially
afterModel hook in the route, while
this.model is the property on the controller, which by default is the same object set on the controller in the default
This can have a number of somewhat-surprising side effects. For example, when navigating out of a given route,
@model will become undefined when the route is torn down, until the model for the new route resolves. However,
this.model will not, since it is a property on the long-lived (normally application-life-long-lived!) controller singleton for the route. While this difference doesn’t normally show up in templates, it can show up if you somehow trigger a promise which references
this.model, or try to refer to it via the destruction hooks in a modifier in a template.
In your specific case, it’s not obvious exactly what the issue is, but I’ve sometimes seen this kind of thing when someone is passing a value from
@model into something which mutates it. I would hypothesize that the way
@model is sort of “frozen” to the result of the
model hook vs. the way that
this.model is just an object property on the controller ends up triggering the assertion when mutating it in some way downstream, including by directly setting properties on it.
Your best bet here to start with would be to identify exactly what is triggering the assertion. My normal workflow here is to have dev tools up, let it hit the assertion, and follow the link in the console back to the assertion. Then set a breakpoint on the assertion, and walk back up the call stack. That will be a bit thorny, as you’ll be fairly deep inside Glimmer’s internals for how it sets values like this, but you should ultimately be able to see what property is being set, on what object, that triggers this specific instance of the assertion.