Failing Script is attached to Button “Duplicate Step and Actions” here: . | Fibery
FYI I resolved this - it was caused by some bugs in my use of Promises.
It would be really great to get better diagnostics than simply “Internal Server Error” 
When this happens, our console.log output is not displayed, so we having no clues to follow.
Could you please share example of misuse of promise in your case, so we can reproduce and see if we can support console.log in activity in that case as well?
Probably with a last improvement I’ve covered not all types of errors. Hoped that console.log statements are written in activity now even when script fails.
1 Like
Well I dug deeper. In case of unhandled promise rejection our script execution engine just fails and we do not have good workaround here. We can just play with the text in error message. e.g. write smth like “Executor terminated unexpectedly”, which is actually what happened. Sorry for that.
1 Like
@Sergey_Truhtanov, I was unable to reproduce the 500 error – hopefully that is good news! 
What would be most helpful for debugging would be to include the script line number of the error. That is why I requested support for Javascript’s Error.stack.
@Sergey_Truhtanov - I found a new example to recreate this error: from this view here
It will work with any entity in the table - just open an entity and execute the Button script called “Causes Server Error 500”
It would also be very helpful if this error would log accumulated console.log() messages:
Failed to execute action "Script": Unable to complete execution during 20000 ms
There is little can do to debug this issue further on my own.
As it is, I can afford to wait around indefinitely for someone to fix this, some day because my Workspace is just for my own research at this point.
But if my Workspace was a client production system, this would be an untenable situation.
I am happy to provide additional information if that is helpful. I have supplied a test case that reliably reproduces this “500 Internal Server Error”, and ten days later there is still no response from the Fibery team.
As a software developer, this does not leave me confident that I can build a production system on this platform, and know that I will receive critical support from the dev team to fix any show-stopper bugs that arise, in a timely manner. 
1 Like
We don’t have access to your workspace by default, so we can’t see the example 
Sorry, I just assumed the team would have some kind of super-admin access to everything.
I am happy to share access to my Workspace with the Fibery Team - just let me know who to add.
We should have mentioned this sooner, sorry. I hope @Sergey_Truhtanov might be able to help (or find someone else who can)
1 Like
Hello there.
Sorry, missed the post. @Matt_Blais – you can either add me to your workspace (truhtanov@fibery.io), or simply post a script text here. With some text description of relations between types, that you use in script. I think it will be enough.
But want to mention once again:
In case of unhandled promise rejection our script execution engine just fails and we do not have good workaround here.
So there will be an error, I can only change its text a bit.
I misunderstood Javascript’s ability to use try/catch with async/await, and tried to do this with Promises explicitly, which apparently does not work 
.
I.e., if you throw inside an async function that is await’ed (and also inside a try block) then you can catch it, but if you throw from inside a .then() callback you must have a .catch() in the Promise chain - an enclosing try/catch will not work there.
Yeah. That seems the problem I’ve written above. In latest NodeJs version your process will crash with “Unhandled promise rejection”. Our script engine is based on NodeJs and fails similarly. I’ll try to change error from “Internal server error” to something meaningful in such cases.
1 Like
I’ve changed error message a bit.
Also have looked with fresh eyes to the code and changed so, that in case of Unhandled Promise, or script timeout, or reaching cpu limits, console.log messages will still be in the output.
Thanks for reporting those suggestions!
1 Like
That should make debugging these issues MUCH easier - Thank you!!! 
2 Likes
I think it makes sense to add this here instead of creating a new topic: @Sergey_Truhtanov:
“Promise.allSettled is not a function” – Why not?
We use nodejs 12.7 at the moment. This API is available in node since 12.9 from what I see.
I hope we will update in some future, but for now it is what we got.
2 Likes
I use await Promise.all() to ensure all the API Promises are completed before the script exits.
My understanding is that if any one of the Promises is rejected, then Promise.all() completes immediately.
Won’t this cause a problem because the script will exit before all the other Promises are completed?
Hello.
Sorry for being a bit late with reply.
That appeared to be a really great question. I didn’t thought about that problem, but it is absolutely valid.
We use nodejs async hooks to track active promises, and in case of Promise.all, our tracking mechanism will still have some promises tracked, but Promise.all would’ve already been rejected and script probably finished. I tried with a simple example and have successfully reproduced the problem.
Promise.allSettled() will help with that, but I think we should probably fix tracking mechanism somehow. Because without fix, Promise.all api will be unreliable to use. And I’m not sure how to educate users to use one api instead of another.
You are the first to report the problem, seems it is quite a rare case, but still.
At the moment I just suggest to go with Promise.all, as in case of fail of one promises, most likely you want your script to fail as well. Difference will be that it can fail with unpleasant “Failed to execute action “Script”: Execution completed but 10 of 28 promises created during execution left in unfulfilled state. Most likely you miss ‘await’ keyword somewhere.” error.
I’ll let know here, if will come up with some solution.
1 Like