The ErrorConstructor is usually just the built-in Error constructor (so I doubt that's where the error happens). We need more info in order to understand the root cause of the problem and the most appropriate fix (although you are probably right that we should be more fault-tolerant inside toDebugString() anyway).

Can you reliably reproduce the error? If so, it would be helpful to get more context about the actual error that is thrown.

Well, since this only happens with the user agent facebookexternalhit, very hard to reproduce on my app with minified code.

Already have invested almost one hour deciphering that and am 99% sure it's a problem in toDebugString and/or serializeObject ...

Yes please, can you make it more fault tolerant pretty please? With more unit test coverages and try-catch blocks skipping the problematic values.

With AngularJS having entered its LTS period, I am a little reluctant to make a change in order to solve a problem we don't fully understand. It would be nice to get more info on this.

So it appears that something in your code is trying to pass the return value from a call to minerr (e.g. this function https://github.com/angular/angular.js/blob/master/src/minErr.js#L101) across a thread boundary (hence the postmessage). It is not related to the ErrorConstructor.

This is not a scenario that AngularJS supports. If you could find exactly where this was happening we could look into it, but otherwise there is not much more we can do.

I hear you. Very difficult to debug or reproduce this scenario here. More weird is that this only happens with the facebookexternalhit user agent.