Array polyfill brings out the "toLowerCase" error

[attilah]

I ran into the same issue described here, but when the SSJS code has a call to DataExtension.Retrieve.

It is unrelated to the test value, it happens if these 2 conditions met:

• Assign a value to Array.prototype.<anything>, number, function, etc...does not matter
• Invoke DataExtension.Retrieve

Also DataExtension.Rows.Retrieve will not return any rows if the polyfills are installed (not just yours, any on Array).

My suspicion is that DataExtension related JS->.Net bindings are only loaded/executed when any method is used on that object and the SFMC JS has a bug for Retrieve, namely that CustomerKey MUST be queried, or internally there is no de.CustomerKey found and it is not checked obviously...because at one of the stellar constellation I was able to get this stacktrace, which included the source line somehow:

Jint.JintException: Object expected: toLowerCase
Line: 544 Char: 16
this._namesFromKeys[de.CustomerKey.toLowerCase()] = de.Name
 - from Jint --> 

 --- inner exception 6---

Jint.Native.JsException: Object expected: toLowerCase
Exception of type 'Jint.Native.JsException' was thrown. - from Jint

Did you find any way to work around it, because it seems that this way the email360 lib is not loadable when you use DataExtension methods.

So if someone using the email360 library, then DataExtension methods starting to fail.

What would you think about as a fix to introduce an ArrayEx type, which can have Array's prototype and extend that with the new methods?

Q: are you shd.lux on MC stackoverflow?

[shdinx]

Thank you @attilah again for your valuable input.
The stacktrace you have shared is the most telling I have seen so far on this issue.
I have spend the last few days again on this issue and I still do not have a fix for it.

When I came across it early 2022 (yes I am shd.lux on MC stackoverflow), I spend days try to understand and fix it without success.

The library is using mainly wsproxy which is superior to Dataextension.Retrieve in my opinion. However, anyone using the library should not be forced to re-write the code and replace Dataextension.Retrieve with wsproxy.

Your suggestion of introducing an ArrayEx type will work but requires some refactoring which I will look into it. There are some areas I use the Array.prototype to make the life easier but I a may change the approach entirely for now and introduce it later.