It doesn’t support replaceAll(), so I guess it must be Node 14 or below. Is there a way to check the exact version? And why do you not update it?
Hi Ooker,
Is there a way to check the exact version?
There is no known way. We do not allow execution of JS code in plain Node env, your code will be sandboxed. As I see it in our documentation, sandboxed process is executed with Node API more-like 12-ish version.
And why do you not update it?
We do not “own” this piece of software. I’d not expect updates in anytime soon.
Why is there no way to know this? Why doesn’t you own it?
1 Like
Why is there no way to know this?
I meant that there is no way to do it by code in the script itself, like asserting process.version. Those things just don’t available in sandbox process. Furthermore it is sandboxed in a way that only selected functions, global objects and methods are available, so it won’t be complete JS api in any case.
Why doesn’t you own it?
Let’s say we have access to source codes, however it is fairly complicated. We do not have time and resources right now to invest in it in this regard.
We have a fairly decent code completion in our JS editor, so you can see which methods are available. Could you describe what for you need the exact version?
In my understanding top-level await is supported only starting from Node 14. Why can we still use top-level await in the automation script?
const Fibery = require('fibery-unofficial');
const fibery = new Fibery({host: "YOUR_ACCOUNT.fibery.io", token: YOUR_TOKEN});
await fibery.entity.updateBatch([
{
'type': 'Cricket/Player',
'entity': {
'fibery/id': '20f9b920-9752-11e9-81b9-4363f716f666',
'Cricket/Full Name': 'Virat \"Chikoo\" Kohli',
'Cricket/Current Team': { 'fibery/id': 'd328b7b0-97fa-11e9-81b9-4363f716f666' }
}
}
]);
Also, is the sandboxed process a docker container?
From Scripts in Automation:
The scripts are executed with Node.js 12, so feel free to use async/await and other recent JS features.
The oldest version that support async/await is 14.8.0. So what the exact version here?
Where did you get this info? Afaik async await is available not only in Nodejs v12 but much earlier.
From MDN. I forgot to specify that I’m referring to the top level await
I can confirm that Node 12 is being used. While it may look like top-level await, it really is not. This solves the mystery! 
1 Like
So what is it if it’s not top-level await? And what’s your recommendation for bundling scripts? I use esbuild with target node12 and it refuses to bundle for having top-level await.
I see how tooling can be confused by this: it looks like top-level await, but in reality, it’s wrapped in a function. I think using the node12 target is still correct as it matches what we use internally. You can also wrap your code in a function like this:
async function main() {
await <something>;
}
main();
1 Like
My code is like:
async function main() {
for (const entity of args.currentEntities) {
...
await http.postAsync(url, { body: obj });
...
}
}
main();
And it results with:
Failed to execute Action "Script": Execution completed but 13 of 17 promises created during execution left in unfulfilled state. Most likely you miss 'await' keyword somewhere.
It should have maximum 3 promises though, as only one entity is triggered. I still need to use await main(). For now using the node15 target is fine for me, but I still want to understand the problem and use node12. Any idea?
Hello.
Suggestion above
async function main() {
await <something>;
}
main();
is not correct. You should explicitly wait for all promises in your script code, otherwise you will get “non-completed promises” exception indeed.
We use node 12 as mentioned above. Nodejs upgrade is not a priority for now, but we will do it at some point in time.
If you want to develop your script outside of Fibery UI, you are free to do this. Just notice that your code is run in sandboxed environment and there can be some differences and limitations in comparison to usual nodejs.
I can’t recommend any particular approach to write code outside fibery UI.
1 Like
Follow-up Stack Overflow question: javascript - Is it possible to tell esbuild to ignore top-level await when bundling to node12 target? - Stack Overflow
Script engine was upgraded to Nodejs 22, so feel free to use all recent apis and language features.
Editor on UI is not yet familiar with some recent Nodejs apis (like Array.flatMap for example), so you may see them underlined with red. But it should work okay. We will fix it with future releases.
3 Likes
This is an exciting update! Do we now have http.patchAsync support?
Unfortunately no.
“http” api is our own code for providing users possibility to make http requests. Basically it’s a wrapper around some nodejs library, with many limitations.
It’s a separate part of work to add methods there. I’ll check how easy is to add patch (should be very easy) and maybe do this, but no promises.
I’ve added patchAsync api to http. Enjoy 
3 Likes