Anyone else seeing '"SUITESCRIPT_API_UNAVAILABLE_I...
# suitescript
s
Anyone else seeing '"SUITESCRIPT_API_UNAVAILABLE_IN_DEFINE" in 2021.1 accounts? I'm seeing this now in an instance where there is no direct suitescript invocation (only a function definition that in turn references
N/record.Type
)
s
I've only ever seen this when trying to define global variables before the entry point of the script that rely upon the modules (like record.Type)
s
this is a regression from previous releases - don't even have to change code, just edit/saving from the script record will trigger it. It's also rather sad that this error even occurs, especially when accessing logical constants (enums) like
record.Type
I thought NS was removing that validation in the file cabinet as it's shown to be erroneous, guess that didn't happen.
c
@stalbert - Yes, seeing this too. I've previously employed this sort of logic
Copy code
if (runtime.executionContext === runtime.ContextType.MAP_REDUCE)
to assign global variables common to all Map/Reduce stages but this now errors in 2021.1 accounts.
We've got an undocumented error code and I'm also pretty sure this was working as it always had when we tested against 2021.1 on a leading accounts a few weeks back.
s
I started noticing this error right after that big outage last week? I wonder if they rolled back the file cabinet validator code
d
@stalbert have you found a solution to your problem? We just got the 2021.1 upgrade and are running into the exact same issue
s
nope - after a long drawn out struggle with NS support they basically said FU and we'd have to change our (previously working fine) code.
d
Ah thats annoying, guess we have to change it too then. Whats weird though is that the code is still working fine for us. The part that causes problems on upload is a custom module thats being used by quite a lot of scripts and all those scripts still work fine. But as soon as I want to upload a script file that uses that module a hell breaks loose
s
yes, that's what's so offensive about this - they are throwing errors for code that works fine. Even more offending is that it's a complete surprise - I saw no mention of this breaking change in the release notes.