Expand my Community achievements bar.

Join us on September 25th for a must-attend webinar featuring Adobe Experience Maker winner Anish Raul. Discover how leading enterprises are adopting AI into their workflows securely, responsibly, and at scale.

Mark Solution

This conversation has been locked due to inactivity. Please create a new post.

SOLVED

Launch implementation: RangeError: Maximum call stack size exceeded

Avatar

Community Advisor

Hi, have run into a problem with our launch implementation without being able to pinpoint the source of this error, maybe someone has any input here:

It starts of with this error: RangeError: Maximum call stack size exceeded

And then 10000 lines of this:

at u (VM35 launch-88-development.min.js:formatted:2902)
at d.x.fetchPermissions (VM35 launch-88-development.min.js:formatted:1403)
at Ne.m.init (VM35 launch-88-development.min.js:formatted:3781)


the particular lines of code it points to are:

return f.optIn.fetchPermissions(u, !0);

 

And:

 

return !i || i && x.isComplete || c ? e(x.permissions) : a || j.add(Ie, function() {
return e(x.permissions)

 

after going through this cycle once the error seems to go away, so i assume it is trying to do something on something that is not yet available to fetch the value of, any suggestion on what to try here? All help greatly appreciated

 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi, for anyone running into a similar error, this was actually caused by the fact that Adobe Target was running an old version of at.js (1.8.0), causing the analytics call to be disrupted by a slow Target request, an update of at.js to 2.3.0 solved this. 

View solution in original post

2 Replies

Avatar

Level 10

I presume you added a custom JS code with a function that calls itself that makes an infinite loop. Review the code.

Avatar

Correct answer by
Community Advisor

Hi, for anyone running into a similar error, this was actually caused by the fact that Adobe Target was running an old version of at.js (1.8.0), causing the analytics call to be disrupted by a slow Target request, an update of at.js to 2.3.0 solved this.