`$_ERROR` Not populating properly in server actions

[karh]

I have a try/catch in my server action where I want to show the $_ERROR.
This variable seems to not populate properly anymore. It doesn't show the value when I try to log $_ERROR.

Reproduce

1. Create a try/catch
2. Put a query in the try, don't set up any settings inside query so it'll fail
3. Add a response step in teh catch where you add the $_ERROR to the 'text' property
   Should look like this:
   
   

Result: empty response

Now add a string next to the error:

It shows the full string and the actual error message:

This is very annoying as we're using the logging extension from @tbvgl
We have MANY server actions where we're catching the error like this:

Which no longer works as a byproduct of whatever is going on here.

Extra debugging information:
When you use a value step to catch the error like so:

Then this value is not set (which I do expect to happen since it's in my catch. Instead of that I get:

However! If you add a string again, it does behave as expected and shows me what's in the 'catch' block:

[karh]

Bump, this is making a lot of our logs useless which leads to being partially blind on production

[patrick]

I assume you use NodeJS, try the following update

server.zip (1.4 KB) Unzip in lib folder

[karh]

Thanks @patrick
Yes NodeJS, this Partially fixes it.
It works in the response step, but I still can’t access it as a variable how I used to do it:

For example in the logging extension:

It does work if I add a string again like before:

Same behaviour for a ‘set value’ step:

But then I add a string before the $_ERROR binding again and it works:

[patrick]

The problem is that in JavaScript an Error object is not serializable in JSON and is ignored. I added an extra replacer function for the JSON output that converts the Error object to a string. Easiest way to output an Error is by using the toString() formatter. I will investigate for some other solutions.

[karh]

Hmm did something change though in your code? I’m confident it was working this way before

[karh]

Bump. Still having problems with this

[karh]

@patrick
Bit of extra info.

As far as I'm aware the $_ERROR variable set by Wappler can be a javascript object, OR a javascript error object.

If it's an error object, the following happens

1. If I try to set a value like

error_raw = {{$_ERROR}}` 

I get

{
  "status": "500",
  "message": "A server error occurred, to see the error enable the DEBUG flag."
}

Which is really not desirable as this is now breaking the rest of the server action (even though this is already in a CATCH)... So just by setting a variable in the catch, the other thing won't run.
Visual:

2. If I set a values like:
   
   I get:

{
  "error_toJSON": "{}",
  "error_toString": "Error: dbconnector.single: sql is required.",
  "something_else": "hi"
}

Which is better as it doesn't break it... but the issue here is that depending on the type of error (normal object or javascript error object) I need a different formatter.

Plus we need to add formatters to all the places where we're just using the $_ERROR as is.
It would be a much better solution if the logic to either stirngify or .toString() is done where you are currently setting the $_ERROR variable in the first place

I swear that this was never an issue before, something must have changed - maybe you can find that change and revert it...

[patrick]

Found the issue, the tryCatch action was still setting the original Error object on the scope.

Here an update: core.zip (2.1 KB) unzip to lib/modules.

[Teodor]

Fixed in Wappler 6.7.1