Repository navigation
Make ErrorConstructor more robust for DataCloneError (v1.7.4) #16707
Description
Activity
The
ErrorConstructoris usually just the built-inErrorconstructor (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 insidetoDebugString()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
toDebugStringand/orserializeObject...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 thepostmessage). It is not related to theErrorConstructor.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.
Seeing lots of those errors in my app:
caused from user agent facebookexternalhit. After some examinations it turns out to happen inside the ErrorConstructor of v1.7.4 itself.
I think the constructor itself should be more stable when an error inside occurs, probably with a try-catch block. My guess is the
toDebugString()fn which calls theserializeObject()fn where this happens, where a cloning attempt is made and fails.There I would make the code more robust.